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.



Simplistix - Content Management, Zope & Python Consulting

Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to