Currently I am hosting my Umbraco media on an Azure blob storage account. I have set up the remote domain in my RemoteDomainWhiteList and everything seems to be working fine with the excepion of remote image caching.
I started to notice that some images coming back from ImageGen were taking quite a bit longer. I did a little troubleshooting and noticed that the uploaded image was around 1.4Mb before being scaled and cropped. That is a large image to scale, but I assumed that ImageGen would be caching to the local disk on the server at that specific cropped size (and it is in the /data folder. There is a cached copy if the image in that directory).
However, when running the site locally and using Fiddler 2 to monitor request on my machine, I noticed that even though the request to ImageGen is coming back as a 304, ImageGen is still making a full request out to get the original Image with a 200 returned taking roughly ~2 second. It appears that with my implementation that ImageGen isn't issuing a conditional request which would allow a 304 to return a cached image from the remote endpoint.
Is that the case or is there a config setting that I need to change to setup remote caching? Is ImageGen making a request to determine if the image has changed? If so, is there a way to turn that off?
I am using ImageGen Professional version 2.9.1.36630
You're correct. ImageGen always compares the source file to be sure it hasn't been replaced since the last request. For local images this is a simple file check and takes almost no time at all. For remote images the source image must be downloaded by ImageGen to make this determination. That means that remote requests will always be less performant than local requests, which don't have the latency and bandwidth issues associated with an http request. If the source image is the same as before, no resizing takes place and cached image is either sent to the new website visitor or a 304 response for the returning visitor. If the source file has changed, resizing takes place again, the previously-cached image is replaced, and the newly resized image is sent to the visitor.
There's no way to turn this aspect of ImageGen off. You can, however, make great performance improvements by using client-side caching in addition to server-side caching with the 'class' feature and timeouts. That way you can dramatically reduce the number of hits your stie has to handle, even the 304 responses. Your server will have more resources avaialble for new requests and returning visitors will have the very fastest response.
Thanks for your response, that makes sense now. However, is there any reason that you don't incorporate a conditional request to the remotely hosted images, allowing for a 304 if the image hasn't been changed? I would expect that it would be more performant to read a response code and return the cached image from disk than request the entire image each time and compare the size/date. As a developer that doesn't have as much experience with requests and caching, this is me being honestly curious and less of a critic of your code.
Also, you mentioned server-side caching with the 'class' feature and timeouts. Can you elaborate on this? I incorporated the CachingTimeSpan tag in hopes that it would solve the issue but I am still seeing the delay. Are there other tags I can implement to improve the server-side performance?
I just responded to your other thread, which deals with this.
The CachingTimeSpan is the element you want to use in your class(es). It sets the number of seconds a browser will consider it's copy of an image to be current. For that period of time, a page will not request those images again from the ImageGen server until after the period has elapsed. If you're confident the source images won't change you can set a very large CachingTimeSpan for your ImageGen class(es). Then, only new visitors to the site will request an image. Or, if you force a reload in the browser you'll make a request to ImageGen, though you'd typically get a 304 response instead of a full image download.
Be aware that using Firebug or a browser's "inspector" doesn't always emulate the real world and often forces downloads of images though you wouldn't think it should. This can lead to confusion during debugging. Fiddler can be a more reliable tool in such cases.
Remote Images and Cache
Greetings,
Currently I am hosting my Umbraco media on an Azure blob storage account. I have set up the remote domain in my RemoteDomainWhiteList and everything seems to be working fine with the excepion of remote image caching.
I started to notice that some images coming back from ImageGen were taking quite a bit longer. I did a little troubleshooting and noticed that the uploaded image was around 1.4Mb before being scaled and cropped. That is a large image to scale, but I assumed that ImageGen would be caching to the local disk on the server at that specific cropped size (and it is in the /data folder. There is a cached copy if the image in that directory).
However, when running the site locally and using Fiddler 2 to monitor request on my machine, I noticed that even though the request to ImageGen is coming back as a 304, ImageGen is still making a full request out to get the original Image with a 200 returned taking roughly ~2 second. It appears that with my implementation that ImageGen isn't issuing a conditional request which would allow a 304 to return a cached image from the remote endpoint.
Is that the case or is there a config setting that I need to change to setup remote caching? Is ImageGen making a request to determine if the image has changed? If so, is there a way to turn that off?
I am using ImageGen Professional version 2.9.1.36630
Any direction would be appreciated!
Hi, Wade,
You're correct. ImageGen always compares the source file to be sure it hasn't been replaced since the last request. For local images this is a simple file check and takes almost no time at all. For remote images the source image must be downloaded by ImageGen to make this determination. That means that remote requests will always be less performant than local requests, which don't have the latency and bandwidth issues associated with an http request. If the source image is the same as before, no resizing takes place and cached image is either sent to the new website visitor or a 304 response for the returning visitor. If the source file has changed, resizing takes place again, the previously-cached image is replaced, and the newly resized image is sent to the visitor.
There's no way to turn this aspect of ImageGen off. You can, however, make great performance improvements by using client-side caching in addition to server-side caching with the 'class' feature and timeouts. That way you can dramatically reduce the number of hits your stie has to handle, even the 304 responses. Your server will have more resources avaialble for new requests and returning visitors will have the very fastest response.
cheers,
doug.
Doug,
Thanks for your response, that makes sense now. However, is there any reason that you don't incorporate a conditional request to the remotely hosted images, allowing for a 304 if the image hasn't been changed? I would expect that it would be more performant to read a response code and return the cached image from disk than request the entire image each time and compare the size/date. As a developer that doesn't have as much experience with requests and caching, this is me being honestly curious and less of a critic of your code.
Also, you mentioned server-side caching with the 'class' feature and timeouts. Can you elaborate on this? I incorporated the CachingTimeSpan tag in hopes that it would solve the issue but I am still seeing the delay. Are there other tags I can implement to improve the server-side performance?
I really appreciate your help on this!
Wade
Hi, Wade,
I just responded to your other thread, which deals with this.
The CachingTimeSpan is the element you want to use in your class(es). It sets the number of seconds a browser will consider it's copy of an image to be current. For that period of time, a page will not request those images again from the ImageGen server until after the period has elapsed. If you're confident the source images won't change you can set a very large CachingTimeSpan for your ImageGen class(es). Then, only new visitors to the site will request an image. Or, if you force a reload in the browser you'll make a request to ImageGen, though you'd typically get a 304 response instead of a full image download.
Be aware that using Firebug or a browser's "inspector" doesn't always emulate the real world and often forces downloads of images though you wouldn't think it should. This can lead to confusion during debugging. Fiddler can be a more reliable tool in such cases.
Hope this helps.
cheers,
doug.
is working on a reply...