For Plone, the standard remedy to this problem is to separate out portal_catalog into it's own storage (zeo has support for serving multiple storages). You may then control the object cache size per storage, setting the one for the portal_catalog storage large enough to keep all it's objects in the cache. As navigation is driven from the catalog this can significantly help performance and reduce the number of zeo loads to only those objects required to traverse to the published object.
Other things that might help: * Reduce the number of zserver-threads from the default 4, object caches are per thread so this allows you to have fewer, larger caches. * Use FileSystemStorage for Archetypes, this can help if you serve many files. Files are stored in 64k pdata chunks, serving a large file can clear your cache. With newer versions of Plone you can use ZODB 3.8 and blobs. * Put Varnish or some other proxy cache in front and cache agressively. * Buy more memory, memory is cheap. Hope that helps, Laurence Juan Pablo Gimenez wrote: > Hi all... > > > I'm profiling a big plone 2.5 instance with huge performance problems > and I was wondering if this bug is still present in zope 2.9.9-final, > http://mail.zope.org/pipermail/zodb-dev/2007-March/010855.html > > We can't increment the zodb-cache-size because we're running out of > memory... so a lot of times we read objects from zeo/zodb... > > Any help will be really appreciated... > > > Saludos... > > > > ------------------------------------------------------------------------ > > _______________________________________________ > For more information about ZODB, see the ZODB Wiki: > http://www.zope.org/Wikis/ZODB/ > > ZODB-Dev mailing list - ZODB-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zodb-dev _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
