SiteAccess vs multiple standalone ez instance, pros & cons, feedback

Previous topic

Setup & design

Next topic

Author	Message
Pablo Pernot	Saturday 02 January 2010 3:10:32 am Just noticed the topic about siteaccess : http://share.ez.no/forums/setup-design/multiple-siteaccess-design-solution I wonder what is your advice about site access versus multiple standalone ez instance. These days I face a huge ezpublish instance (with around ~30 siteaccess, and for each one 3 translations). Every siteaccess have his own content, but nodes with multiple locations are spread within multiples siteaccess. Some workflow copy new publication from one subtree to another (every siteaccess has his own subtree I forgot to mention). It works well, so it's ok for me. If I should start this project again I really wonder If it will be more smart to use multiple ezpublish standalone instance for every siteaccess. Pros : maintenability simplicity of code (=> maintenability) simplicity of database management (right now everything is within the same db) I can disable/enable siteaccess more easily, All the roles, policies and workflows are centralized, it's a pain for modularity etc. Cons : It works ! why should I change it ! It's easy to setup multiple locations for the same node It's easy to copy object within subtrees. All the roles, policies and workflows are centralized, it's easier. etc. Your advice ? your feedback ? What about server load ? thanks Happy new year, hope to meet you in Switzerland in january Pablo Pablo Pernot http://www.smartview.fr http://www.areyouagile.com
Nicolas Pastorino	Monday 01 February 2010 8:26:03 am Hi Pablo, For security purposes a total isolation of applications may be required. Meaning no single line of code, nor any resource shoul dbe shared. In this case you need to have separate instances. As well, when one eZ Publish instance hosts say 2 applications, which have different evolution paces, the tie-in of the 2 applications being on the same instance may reduce flexibility and prevent from having 2 very different evolution/maintenance paces. I think we should enhance the initial thread with these considerations, should bring up useful points: http://share.ez.no/forums/setup-d.../multiple-siteaccess-design-solution My 2 cents, cheers, -- Nicolas Pastorino Director Community - eZ Member of the Community Project Board eZ Publish Community on twitter: http://twitter.com/ezcommunity t : http://twitter.com/jeanvoye G+ : http://plus.tl/jeanvoye

Author

Message

Pablo Pernot

Saturday 02 January 2010 3:10:32 am

Just noticed the topic about siteaccess :

http://share.ez.no/forums/setup-design/multiple-siteaccess-design-solution

I wonder what is your advice about site access versus multiple standalone ez instance.

These days I face a huge ezpublish instance (with around ~30 siteaccess, and for each one 3 translations). Every siteaccess have his own content, but nodes with multiple locations are spread within multiples siteaccess. Some workflow copy new publication from one subtree to another (every siteaccess has his own subtree I forgot to mention).

It works well, so it's ok for me.

If I should start this project again I really wonder If it will be more smart to use multiple ezpublish standalone instance for every siteaccess.

Pros :

maintenability
simplicity of code (=> maintenability)
simplicity of database management (right now everything is within the same db)
I can disable/enable siteaccess more easily,
All the roles, policies and workflows are centralized, it's a pain for modularity
etc.

Cons :

It works ! why should I change it !
It's easy to setup multiple locations for the same node
It's easy to copy object within subtrees.
All the roles, policies and workflows are centralized, it's easier.
etc.

Your advice ? your feedback ? What about server load ?

thanks

Happy new year, hope to meet you in Switzerland in january

Pablo

Pablo Pernot
http://www.smartview.fr
http://www.areyouagile.com

Nicolas Pastorino

Monday 01 February 2010 8:26:03 am

Hi Pablo,

For security purposes a total isolation of applications may be required. Meaning no single line of code, nor any resource shoul dbe shared. In this case you need to have separate instances.
As well, when one eZ Publish instance hosts say 2 applications, which have different evolution paces, the tie-in of the 2 applications being on the same instance may reduce flexibility and prevent from having 2 very different evolution/maintenance paces.

I think we should enhance the initial thread with these considerations, should bring up useful points: http://share.ez.no/forums/setup-d.../multiple-siteaccess-design-solution

My 2 cents,
cheers,

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye

eZ debug

Timing:	Jan 15 2025 08:04:52
Script start
Timing:	Jan 15 2025 08:04:52
Module start 'layout'
Timing:	Jan 15 2025 08:04:52
Module start 'content'
Timing:	Jan 15 2025 08:04:52
Module end 'content'
Timing:	Jan 15 2025 08:04:52
Script end

Main resources:

Total runtime	0.0233 sec
Peak memory usage	4,096.0000 KB
Database Queries	3

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0076	685.0781	183.7188
Module start 'layout'	0.0076	0.0035	868.7969	52.6094
Module start 'content'	0.0111	0.0071	921.4063	173.8906
Module end 'content'	0.0182	0.0050	1,095.2969	751.7578
Script end	0.0232		1,847.0547

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0050	21.4816	14	0.0004
Check MTime	0.0015	6.3561	14	0.0001
Mysql Total
Database connection	0.0007	3.1811	1	0.0007
Mysqli_queries	0.0053	22.9627	3	0.0018
Looping result	0.0000	0.0737	1	0.0000
Template Total	0.0043	18.3	1	0.0043
Template load	0.0034	14.3989	1	0.0034
Template processing	0.0009	3.9027	1	0.0009
Override
Cache load	0.0030	12.6773	1	0.0030
General
dbfile	0.0020	8.3837	8	0.0002
String conversion	0.0000	0.0307	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded	Edit	Override
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 1 Number of unique templates used: 1

Time used to render debug report: 0.0001 secs