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 - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -