[Zope] Zope scalabilty and problems

[Chris Withers]

Kennamore, Matthew G [NTK] wrote:
> 
> The Technologies we are using are Zope, Zeo, plone and so forth.  Why are we having these large issues?  

It depends entirely on your application.

Plone doesn't help you here, and I'd certainly consider replacing that 
long before I think about trying to ditch ZODB in favour of a relation 
back end (something I find confusing, since a relational db can be just 
as slow if you mistreat it in the ways people often mistreat ZODB - 
"Data.fs", ie: FileStorage, is about as fast as it gets when used correctly.

As I said, Plone doesn't help you here, and it, and the coding styles it 
encourages, along with Archetypes myriad layers of indirection are 
likely to be the source of your problem.

I'd start with:

- make sure requests that shouldn't be writing to the ZODB aren't 
writing to the ZODB - The Undo tab in the root of your Zope instance is 
good for that, it shouldn't have any entries for views on it

- get PTProfiler up and running and profile your most commonly used 
urls, try and knock on the top file slowest items on the profile 
results, or at least make them not slow anymore

- look at doing some clever coding, portal_catalog search and AT 
references are the worst offendors for hopelessly slow code that you'd 
expect to be fast.

- finally, start looking at app-level caching, things like CMF's 
cookedBody can be applied more widely as techniques.

- at this point, look at systemic caching such as Squid, ESI, etc. This 
is much harder if you need to have authenticated users.

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk