How many objects can eZPublish handle?

Author Message

Ivo Lukac

Monday 16 June 2008 6:22:45 am

Is there some real experience on where are the practical limits? One million objects maybe?
At which point system is no longer usable?

What is the bottleneck for this? meta database model or tree model or something else?

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?

Thanks for any info

http://www.linkedin.com/in/ivolukac
http://www.netgen.hr/eng/blog
http://twitter.com/ilukac

Piotrek Karaƛ

Thursday 23 October 2008 7:08:43 am

I support these questions ;)

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Ivo Lukac

Thursday 23 October 2008 8:10:36 am

It is rather sad that nobody answered in 3 month :(

http://www.linkedin.com/in/ivolukac
http://www.netgen.hr/eng/blog
http://twitter.com/ilukac

Gaetano Giunta

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

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.