File contents
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="generator" content="Docutils: http://docutils.sourceforge.net/">
<link rel="stylesheet" href="default.css" type="text/css" />
<title>Optimising Zope</title>
<meta name="author" content="Richard Jones, with comments from Anthony Baxter, Bakhtiar A Hamid and Chris Withers." />
</head>
<body>
<div class="document" id="optimising-zope">
<h1 class="title">Optimising Zope</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr><th class="docinfo-name">Author: </th><td>
Richard Jones, with comments from Anthony Baxter, Bakhtiar A Hamid
and Chris Withers.</td></tr>
</tbody>
</table>
<p>We (<a class="reference" href="http://www.ekit.com/">http://www.ekit.com/</a>) have a popular website, and it's hit fairly hard
(around a 6 hits <a class="footnote-reference" href="#id4" id="id1" name="id1">*</a> a second). I've therefore been working on ways to get Zope
to go as fast as possible. Here's some hints for others who are running (or
are expecting to run) high-volume Zope sites:</p>
<ol class="arabic">
<li><p class="first">CallProfiler up the wazoo. Perform lots of CallProfiler analysis and
fixing of hotspots. We managed halve our average page load time just
doing this.</p>
</li>
<li><p class="first">Use RAM caches in Zope - find the HTML chunks that don't get changed for
every visitor (but rather large groups or all visitors). Use the
CallProfiler to isolate calls that change very little between users. RAM
cache those. Again, we have achieved halving, or more, through caching
just a couple of common components.</p>
</li>
<li><p class="first">Make static content (images, stylesheets and some pages) cacheable. Put
stylesheets and images in an area of your Zope that isn't authenticated
by cookies. Most browsers won't cache images or a stylesheet if a cookie
was sent along with the request. Similarly, don't request stuff by HTTPS
when you don't need to - not only does the server have to do more work,
but the client won't cache anything served by HTTPS. There's a neat tool
out there that does cacheability testing:</p>
<blockquote>
<p><a class="reference" href="http://www.mnot.net/cacheability/">http://www.mnot.net/cacheability/</a></p>
</blockquote>
<p>Getting caching right in Zope can be quite a challenge - you may wish to
just skip this and use a method like we did in 6b below.</p>
</li>
<li><p class="first">ZEO clients - we have about 9 of them, spread over a number of CPUs. We'll
be putting in some more real soon. If your Zope servers are CPU-bound, then
extra ZEO clients will only help.</p>
</li>
<li><p class="first">Don't change the ZODB unless it's absolutely necessary. Changes to the ZODB
things down considerably. Use of a backend high-performance database like
Oracle is a very good idea.</p>
</li>
<li><p class="first">Use a front-end cache for static content. There's two ways to do this:</p>
<ol class="loweralpha simple">
<li>Throw in squid and stuff will be served much much faster. This assumes
that the content is cacheable - see point 3.</li>
<li>We use apache frontends using FastCGI <a class="footnote-reference" href="#id5" id="id2" name="id2">†</a> to the ZEO clients. They have
an on-disk cache which serves up images (using rewrite rules to trap
image URLs before they are sent to Zope) meaning Zope can do more
important stuff than serve up static binary files. This halves the
average page load time - our pages have between 50 and 120 images (yes,
120 images is a lot and falls under the general rules for optimising
HTML pages).</li>
</ol>
</li>
<li><p class="first">Python won't make use of multiple processors <a class="footnote-reference" href="#id6" id="id3" name="id3">‡</a> so if you have them
available, you are strongly advised to set up at least one ZEO client per
processor (on fast machines, having more than one can sometimes be another
performance boost).</p>
</li>
</ol>
<table class="footnote" frame="void" id="id4" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id1" name="id4">[*]</a></td><td>Where a "hit" is a distinct HTTP fetch.</td></tr>
</tbody>
</table>
<table class="footnote" frame="void" id="id5" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id2" name="id5">[†]</a></td><td>FastCGI may be replaced by ProxyPass - whatever you're comfortable
with.</td></tr>
</tbody>
</table>
<table class="footnote" frame="void" id="id6" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id3" name="id6">[‡]</a></td><td>This is due to the <a class="reference" href="http://www.python.org/doc/current/api/threads.html">Global Interpreter Lock</a> in Python.</td></tr>
</tbody>
</table>
</div>
<hr class="footer"/>
<div class="footer">
<a class="reference" href="zope_optimisation.txt">View document source</a>. Generated on: 2002-08-26. Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source. </div>
</body>
</html>
Log in
Forgot your password?
