Hi Folks! We have developed a nice CMS ontop of Zope, that dynamically renders pages (with DTML and a python Product) out of special Components (e.g. text blocks and headlines). The only bad thing is: The Performance really sucks. I experienced that Zope is able to serve ~50 REQUESTs per Second on a small static page (where apache does 1500-2200), but under heavy DTML- and Python usage, Zope will only be able to serve ~ 0,5 - 5 pages per second (depending on how big the page is and how complicated its python logic). Well, i am aware of the fact that cache managers are able to dramatically improve performance, but in most cases, our content and pages are just too dynamic for the application to work w/ enabled cache (RAM or HTTP or ProxyPass). Does anyone know some hints how to get more performance out of zope? Any common Python / DTML routines that cost way too much time? Any experiances in improving Zope's speed? System is Zope-2.5.1 on FreeBSD-4-Stable and Python 2.1.3. Hardware: Tested on Xeon / 1,26GHz / 512MB RAM and Athlon / 850MHz / 256MB RAM Thanks in advance! regards, Klaus -- Goelz & Schwarz GmbH Waltherstrasse 29, 80337 Muenchen, Germany phone: + 49 - (0)89 / 54 46 70 - 0 fax: +49 - (0)89 / 54 46 70 - 10 e-mail: klaus.herrmann@goelz.com web: http://www.goelz.com
IMHO great performance must be "designed into" the application and considered from very early on in the design stage. i have a feeling no one really thought about performance when you guys wrote that CMS system... it will be hard to slap something on top (other than "more hardware") that will give you the performance you want. jens On Thursday, July 25, 2002, at 09:02 , Klaus Herrmann wrote:
Hi Folks!
We have developed a nice CMS ontop of Zope, that dynamically renders pages (with DTML and a python Product) out of special Components (e.g. text blocks and headlines). The only bad thing is: The Performance really sucks.
I experienced that Zope is able to serve ~50 REQUESTs per Second on a small static page (where apache does 1500-2200), but under heavy DTML- and Python usage, Zope will only be able to serve ~ 0,5 - 5 pages per second (depending on how big the page is and how complicated its python logic).
Well, i am aware of the fact that cache managers are able to dramatically improve performance, but in most cases, our content and pages are just too dynamic for the application to work w/ enabled cache (RAM or HTTP or ProxyPass).
Does anyone know some hints how to get more performance out of zope? Any common Python / DTML routines that cost way too much time? Any experiances in improving Zope's speed?
System is Zope-2.5.1 on FreeBSD-4-Stable and Python 2.1.3. Hardware: Tested on Xeon / 1,26GHz / 512MB RAM and Athlon / 850MHz / 256MB RAM
Thanks in advance!
regards, Klaus
On Thursday 25 Jul 2002 2:02 pm, Klaus Herrmann wrote:
Any common Python / DTML routines that cost way too much time?
Im sure there will be, but they will be specific to your application.
Any experiances in improving Zope's speed?
I suggest you double-check your conclusion about caching.
Klaus Herrmann writes:
We have developed a nice CMS ontop of Zope, that dynamically renders pages (with DTML and a python Product) out of special Components (e.g. text blocks and headlines). The only bad thing is: The Performance really sucks. ... Does anyone know some hints how to get more performance out of zope? Any common Python / DTML routines that cost way too much time? Any experiances in improving Zope's speed? Zope partially supports Python's "profile" features. See "Control_Panel -> Debugging Information -> Profiling".
Analyse the profile to find hotspots and start optimizing them. For a higher level analysis, there is the "CallProfiler" product. Dieter
On Thu, 25 Jul 2002 11:02 pm, Klaus Herrmann wrote:
Does anyone know some hints how to get more performance out of zope? Any common Python / DTML routines that cost way too much time? Any experiances in improving Zope's speed?
Have you used the CallProfiler to identify the hotspots yourself? See http://www.zope.org/Members/richard/docs/zope_optimisation.html for other ideas. It may be that some of your pages might be broken up into cacheable bits that depend on fewer variables (we have sections of our site that end up having about 300 combinations (IIRC) yet the performance gain outweighs the cost of having them cached) Richard
participants (5)
-
Dieter Maurer -
Jens Vagelpohl -
Klaus Herrmann -
Richard Jones -
Toby Dickenson