Re: Accelerating images without proxy
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.
I checked the logs and then some HTML. We did tell the web designers (customer's choice of design agency) to reference all images with absolute url (well, always start with the slash, e.g "/images/navigation/home.gif", but they didn't (so they are: "images/navigation/home.gif"). And there are hardly any 304 codes in the log. Would in this case an Accelerated HTTP Cache Manager help? I am afraid I would need to skim through about 100 files and change the HTML otherwise. Cheers Marc
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Marc Burgauer Sent: Tuesday, April 22, 2003 3:44 PM To: zope@zope.org Subject: [Zope] Re: Accelerating images without proxy
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.
I checked the logs and then some HTML. We did tell the web designers (customer's choice of design agency) to reference all images with absolute url (well, always start with the slash, e.g "/images/navigation/home.gif", but they didn't (so they are: "images/navigation/home.gif"). And there are hardly any 304 codes in the log.
Would in this case an Accelerated HTTP Cache Manager help?
Yes, it will. Try testing your engine with a cacheability tester: http://www.mnot.net/cacheability/ In my experience, Zope was actually pretty lousy about setting cache headers until I added the AHCM. This was made more complicated by the addition of the apache proxy in front of zope. Beware that once you get the AHCM added and working, uploading images in zope can be disconcerting. If upload a new image into an existing object, the preview will still show the old image until you force a reload. It's harmless but strange.
Charlie Reiman wrote:
I checked the logs and then some HTML. We did tell the web designers (customer's choice of design agency) to reference all images with absolute url (well, always start with the slash, e.g "/images/navigation/home.gif", but they didn't (so they are: "images/navigation/home.gif"). And there are hardly any 304 codes in the log.
Would in this case an Accelerated HTTP Cache Manager help?
Yes, it will.
Not to nitpick, just to clarify for Marc, but no headers (that I know of) will help any proxy/browser cache to find out that /images/navigation/home.gif is the same image as /spam/images/navigation/home.gif Taken to the extreme, there could be an enourmous amount of strings instead of "spam" -> uncacheable. So, how would an AHCM help? cheers, oliver
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Oliver Bleutgen Sent: Tuesday, April 22, 2003 5:22 PM To: zope@zope.org Subject: Re: [Zope] Re: Accelerating images without proxy
Charlie Reiman wrote:
I checked the logs and then some HTML. We did tell the web designers (customer's choice of design agency) to reference all images with absolute url (well, always start with the slash, e.g "/images/navigation/home.gif", but they didn't (so they are: "images/navigation/home.gif"). And there are hardly any 304 codes in the log.
Would in this case an Accelerated HTTP Cache Manager help?
Yes, it will.
Not to nitpick, just to clarify for Marc, but no headers (that I know of) will help any proxy/browser cache to find out that /images/navigation/home.gif is the same image as /spam/images/navigation/home.gif Taken to the extreme, there could be an enourmous amount of strings instead of "spam" -> uncacheable. So, how would an AHCM help?
cheers, oliver
I guess I misread the posting. Generally in zope you don't use direct URL at all to refer to an image. You should instead get the object and ask it what it's URL is. If they must place image URLs in raw text, then don't use Zope for your images. You aren't gaining anything. Use an apache front end, proxy through part for Zope (using VHM) and part for the images. Stick the images on Apache and be done with it. To be really cheeky, a 302 response should be sufficient to tell the browser that /spam/images/navigation/home.gif is the same image as /images/navigation/home.gif. But that's not what your looking for.
Charlie Reiman wrote:
I guess I misread the posting. Generally in zope you don't use direct URL at all to refer to an image. You should instead get the object and ask it what it's URL is.
If they must place image URLs in raw text, then don't use Zope for your images. You aren't gaining anything. Use an apache front end, proxy through part for Zope (using VHM) and part for the images. Stick the images on Apache and be done with it.
To be really cheeky, a 302 response should be sufficient to tell the browser that /spam/images/navigation/home.gif is the same image as /images/navigation/home.gif. But that's not what your looking for.
Well, but you are on to a new product here, ZImageDemoronized: class ZImageDemoronized(Image): def index_html(self,REQUEST): if REQUEST['URL0'] != self.absolute_url(): return REQUEST.RESPONSE.redirect(self.absolute_url()) ;) cheers, oliver
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Oliver Bleutgen Sent: Wednesday, April 23, 2003 9:58 AM To: zope@zope.org Subject: Re: [Zope] Re: Accelerating images without proxy
Charlie Reiman wrote:
I guess I misread the posting. Generally in zope you don't use
direct URL at
all to refer to an image. You should instead get the object and ask it what it's URL is.
If they must place image URLs in raw text, then don't use Zope for your images. You aren't gaining anything. Use an apache front end, proxy through part for Zope (using VHM) and part for the images. Stick the images on Apache and be done with it.
To be really cheeky, a 302 response should be sufficient to tell the browser that /spam/images/navigation/home.gif is the same image as /images/navigation/home.gif. But that's not what your looking for.
Well, but you are on to a new product here, ZImageDemoronized:
class ZImageDemoronized(Image): def index_html(self,REQUEST): if REQUEST['URL0'] != self.absolute_url(): return REQUEST.RESPONSE.redirect(self.absolute_url())
I suppose you could make a case that this should be optional behavior: Sort of a "canonical access only" mode. It really only make sense for static content where acquisition isn't relevent. But it would still be an interesting option and would help with caching. I'll thow it in my bag-o-tricks.
participants (3)
-
Charlie Reiman -
Marc Burgauer -
Oliver Bleutgen