Login to your Zope site as a user with Manager rights, and navigate to your Plone Site in the ZMI. Click the HTTPCache, and then look at the Associate tab. Notice that no items are currently associated with it.

When associating items with the HTTPCache, you're not associating content items, instead you associate the different views available. This means that you can ensure that your view template is cached, but edit templates are not. Ensuring that the options All for Locate Cacheable Objects and All for Of the type(s), and Search Subfolders are all selected, click the Locate button. After a few moments, you should get a list of all the skin items in your site back.

Pay close attention to which items you select from this list. You can safely cache all images, all files, all CSS, and all Javascripts. In addition, you should ensure that the view templates for all of your available content types are being cached. (For example, newsitem_view for News Items.) Be especially sure to check that any items that you have customised into a different skin folder have also been selected.

Now you should have a very long list of items to cache, so just click to save your changes.

IMPORTANT: If you select templates that are located on the file system, the association with a cache manager will not persist, so it will be gone the next time you restart the server. Do create persisting cache manager associations, you should use the .metadata files on the file system. For examples, look at any of the files in plone_images.

Assuming that you have done this correctly, you should now find that Apache is starting to cache your pages. We can test this by using wget, and outputting the HTTP response:

 wget -sS --delete-after http://yoursite.com/

 --03:28:46-- http://yoursite.com/
 => `index.html'
 Resolving yoursite.com... done.
 Connecting to yoursite.com[WWW.XXX.YYY.ZZZ]:80... connected.
 HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Date: Mon, 19 Jan 2004 03:28:46 GMT
 3 Server: Zope/(unreleased version, python 2.3.2, linux2) ZServer/1.1 Plone/2.0-RC3
 4 Vary: Accept-Encoding
 5 Content-Length: 32125
 6 Expires: Mon, 19 Jan 2004 04:28:43 GMT
 7 Last-Modified: Mon, 19 Jan 2004 03:28:43 GMT
 8 Cache-Control: max-age=3600
 9 Content-Type: text/html;charset=utf-8
 10 Age: 4
 11 X-Cache: HIT from yoursite.com
 12 Connection: close

Notice that now the X-Cache header is showing a cache HIT. This is exactly the result that we want. Now that Apache is caching the results of your Plone pages, you can test to see what kind of difference this has made. Once again, using the Apache Benchmark utility, we can test the site:

 /usr/sbin/ab -n 100 http://yoursite.com/

 Benchmarking yoursite.com (be patient).....done
 Server Software: Zope/(unreleased
 Server Hostname: yoursite.com
 Server Port: 80

 Document Path: /
 Document Length: 32125 bytes

 Concurrency Level: 1
 Time taken for tests: 0.116 seconds
 Complete requests: 100
 Failed requests: 0
 Broken pipe errors: 0
 Total transferred: 3252200 bytes
 HTML transferred: 3212500 bytes
 Requests per second: 862.07 [#/sec] (mean)
 Time per request: 1.16 [ms] (mean)
 Time per request: 1.16 [ms] (mean, across all concurrent requests)
 Transfer rate: 28036.21 [Kbytes/sec] received

Note particulary the time taken for this test: 0.116 seconds, or a much healtier 0.0016 seconds per request! This gives some indication of how fast this site will be capable of running.

Using Apache Benchmark to conduct 100 consecutive requests is hardly indicative of the true speed at which your site is running, however. To put this setup through its paces, try using the concurrency feature, which allows you to run requests simultaneously. In this example, ab runs 100000 requests with 100 request concurrency. This is the equivalent of an entireprise-level site under medium to heavy load:

 /usr/sbin/ab -n 100000 -c 100 http://yoursite.com/

 Benchmarking yoursite.com (be patient)
 Server Software: Zope/(unreleased
 Server Hostname: poked.org
 Server Port: 80

 Document Path: /
 Document Length: 32125 bytes

 Concurrency Level: 100
 Time taken for tests: 115.732 seconds
 Complete requests: 100000
 Failed requests: 0
 Broken pipe errors: 0
 Total transferred: -1041856680 bytes
 HTML transferred: -1081567796 bytes
 Requests per second: 864.07 [#/sec] (mean)
 Time per request: 115.73 [ms] (mean)
 Time per request: 1.16 [ms] (mean, across all concurrent requests)
 Transfer rate: -9002.32 [Kbytes/sec] received

These results show that the combination of Apache and Zope is capable of serving 100000 requests in just under 2 minutes. It's worth pointing out again that this is on a 1.8GHz Intel Celeron with only 128MB of RAM, running a basic Redhat 7.3 setup, which is very, very slow for a production server. On a typical Dual Intel Xeon 2.4GHz server with 1GB of RAM, expect a speed increase of over 100%.

It is worth pointing out that there is are limitations to this approach to caching. In setting the Last-Modified header to the time of the page being rendered, and setting the max-age to 3600 seconds, all content on the site has a lifetime of 1 hour. This means that in the worst-case scenario, an update to the site could take an hour to appear. This can be resolved by forcing a cache invalidation for a particular page, which can be done by simply CTRL-refeshing the page in most browsers.

Another limitation is that, if you are using your main domain name to login and edit your Plone site, you may experience some strange behaviour in browsers that do not properly respect caching headers (such as Internet Explorer). An easy way to work around this is to add a new subdomain for users who are editing your site, such as cms.yoursite.com. Then, in your Apache config file, simply add a new VirtualHost section for your CMS view, without any of the caching directives:

 <VirtualHost *>
 ServerName cms.yoursite.com
 ServerAdmin webmaster@yoursite.com
 ProxyPass / http://cms.yoursite.com:8080/VirtualHostBase/http/cms.yoursite.com:80/yourplonesite/VirtualHostRoot/
 ProxyPassReverse / http://cms.yoursite.com:8080/VirtualHostBase/http/cms.yoursite.com:80/yourplonesite/VirtualHostRoot/
 </VirtualHost>

Thus, anyone who needs to edit the site will bypass the caching entirely.