Maik Jablonski wrote:
Marc Burgauer wrote:
I have analysed the problem and I believe I could get a major boost if we could just cache some images. There are about two dozen images, mainly logos and navigation images that are used on almost every page. If I could just cache these, that should help a lot.
I looked into the various internal mechanisms (Accelerated HTTP Cache Managers, Cache-tab on image object) and read the help. But I'm still not sure if this is helpful. The help text constantly tells me that some operations using cache can backfire and become more expensive.
Can anybody share any light on this issue, please?
You should use an Accelerated HTTP Cache Manager, which only caches your images (see Tab: Associate -> Select "Image"). This will add some additional headers to the image-responses which tell proxies on the way or the clients browsers to cache the images for the specified time. All your clients won't request the images anymore from the server which should take some load from the server.
Images delivered by zope are quite extensively cached on the browser side per default, even without configuring something in zope. I.e. zope sends appropriate "not modified" headers if it gets the right request from the browser (which nearly all browsers do). You can see this when grepping the logs for "304", or using a log analyzer. I just checked on two sites of us, and on one, which has many different images, I get 10% of all responses to be "304", while on the other, whose images consist mainly of navigation buttons, I get 50% of all images cached. This was btw. a big problem for us using localizer, because when switching languages because the images wouldn't change. Since sending the 304 shouldn't be expensive, I doubt it will help much for the speed of the site, but esp. not if it is network I/O bound. One thing which is important is to link the navigation images with their absolute url, not using acquisition, so that the browser will be able to see that the images are identical. cheers, oliver