|
Thursday 23 October 2008 11:20:57 am
<i>Is there some real experience on where are the practical limits? One million objects maybe?</i>
Hard to give an estimate based on number of objects. It depends on:
- attributes per object
- languages per object
- object versions per object
- object relations per object 1 million is not a pain point, most likely. 10 millions could be. <i>At which point system is no longer usable?</i> It depends on the definition of "usable". Editors often have a very different pov than users (eg. preview-generation time can be all to them, but it has little correlation to front-end performance). <i>What is the bottleneck for this? meta database model or tree model or something else?</i> The database model of eZP is built for flexibility (eg class definition via backoffice), not speed. It usually becomes a bottleneck at some point.
But there are just so many factors that is very hard to give a real estimate:
- bad templates can kill an eZP site with 10000 objects
- cache-block tuning can be a subtle art. Use them, but don't overdo them
- smart-view-cache configuration is a subtle art, too
- static cache can improve a lot response times if generating a page template takes too long, but it imposes heavy requirements on design of the site
- do not put too many objects inside a single parent folder
- be careful with workflows
<i>What can be done to prepare for this:
- reduce number of attributes per object?
- something else?
What can be done when we reach the limits:
- reduce number of versions?
- disable smart view cache?
- go to clustering?
- something else?</i> See above for some hints.eZ cluster will not help very much - if at all - with scaling the number of objects. Reduce number of versions stored. Instead of disabling smart cache, check CacheThreshold in site.ini.
Principal Consultant International Business
Member of the Community Project Board
|
