Steve Park
Registered Users
Nuke Active Member
Posts:30
 |
| 2/28/2007 11:18 AM |
|
Hi,
RE: latest version of Simple Gallery there are some bug fixes I would like to see before further functionality is introduced (actually I am super-happy w/ the feature set). The RSS feed is not validating correctly (invalid tokens) According to feed validator.org.
RSS Validation Results
More important, the image caching is not working correctly. In the case of Random Gallery (I didn't check the individual galleries) the browser is requesting the image on each page hit & hammering the performance pretty bad. To get optimum performance the response stream needs the post-check & pre-check headers added. Here is a good article describing how to do it in ASP.Net 2.0 (simple changes). I am using Microsoft Fiddler HTTP Debugger to inspect the HTTP requests coming out of the client & server responses. This is how I can tell we are still getting requests back to the server for each random image.
OTOH gallery has been running for 8 months on site w/ reasonable traffic & no headaches / crashes & I'd recommend it to anyone. If we can get the RSS / caching issues resolved I would consider the gallery to be pretty much invincible. |
|
|
|
|
Steve Park
Registered Users
Nuke Active Member
Posts:30
|
| 2/28/2007 11:22 AM |
|
| Sorry forgot to mention in our case we'd like to see post-check interval of 1-2 days or even longer since we rarely(never) change images once they're posted to the galleries |
|
|
|
|
Scott McCulloch
Administrators
Nuke Master
Posts:12450
|
| 3/01/2007 7:16 AM |
|
Is the caching working for the standard module? But not the random gallery? Is that correct?
The RSS is a difficult one, I need that additional LinkThumbnail tag for the XSL stylesheet. I don't know why it would not validate for that reason, because it's an extra element and the core XML still supports the basic stuff. Do you have any ideas?
As for the GUID, I'll see what I can do. |
|
Scott McCulloch
Site Administrator |
|
|
Steve Park
Registered Users
Nuke Active Member
Posts:30
|
| 3/01/2007 9:03 AM |
|
Looks like anything routed through ImageHandler.ashx is getting a full re-fetch on 2nd/3rd etc page hits (as opposed to a 304 not-modified, or best would be not to make the request at all if the post-check is set). Once I get into the album w/ a single photo on the page (ie, the url is like /Portals/0/Gallery/Album/12/Beyonce.jpg) I'm seeing a 304 which is as expected. However, I think it's IIS' job to provide the 304 on the raw images. It's only the ashx that you'd need to set the headers programatically since IIS will always assume .aspx / ashx extensions are dynamic content. Actually, looking at the Fiddler stuff again just now I'm reminded that the URL's that the simple gallery generates associated w/ imagehandler.ashx are kinda fat & not likely to be crawled by the search engines:
"/DesktopModules/SimpleGallery/ImageHandler.ashx?width=50&height=75&HomeDirectory=%2fPortals%2f0%2fGallery%2fAlbum%2f12&fileName=Beyonce+Hot.jpg&portalid=0&i=795&q=1"
But that's a secondary consideration. Testing was done with IE6. The Temporary Internet Files / Settings is set to "Automatic" which is what most people have on their systems. Obviously we're not in a position to ask people change that. |
|
|
|
|
Steve Park
Registered Users
Nuke Active Member
Posts:30
|
| 3/01/2007 10:09 AM |
|
In playing around w/ the IIS custom headers some more I see that the correct behaviour is achieved for images by adding the max-age Cache-Control header, ie:
Cache-Control: max-age=86400
The post-check / pre-check headers don't seem necessary if you have this one (one of the comments in the article I pointed you to mentions this as well). Likely you'd be in business if you added this header to the imagehandler.ashx code |
|
|
|
|
Scott McCulloch
Administrators
Nuke Master
Posts:12450
|
| 3/01/2007 9:12 PM |
|
"I'm reminded that the URL's that the simple gallery generates associated w/ imagehandler.ashx are kinda fat "
They need to be this length at the moment, as on each request I would have to do a DB hit to get dimensions, file name, path, etc. I could do some caching there to improve the URLs though.
Here is the caching that I do at the moment:-
context.Response.Cache.SetCacheability(HttpCacheability.Public)
context.Response.Cache.SetExpires(DateTime.Now.AddDays(1))
context.Response.Cache.VaryByParams("FileName") = True
context.Response.Cache.VaryByParams("HomeDirectory") = True
context.Response.Cache.VaryByParams("Width") = True
context.Response.Cache.VaryByParams("Height") = True
I think this is just caching the ouptut though, and probably not telling the browser to not go and request the file again.
What do you think? |
|
Scott McCulloch
Site Administrator |
|
|
Scott McCulloch
Administrators
Nuke Master
Posts:12450
|
| 3/01/2007 9:14 PM |
|
Here is the explanation of SetCacheability:-
Sets Cache-Control: public to specify that the response is cacheable by clients and shared (proxy) caches. |
|
Scott McCulloch
Site Administrator |
|
|
Steve Park
Registered Users
Nuke Active Member
Posts:30
|
| 3/02/2007 8:53 AM |
|
Ok, first thing is that on my current setup w/ Simple Gallery @02.01.03 / SimpleGalleryRandom @01.09.08. I hope my SimpleGalleryRandom is the most current??
Fiddler is showing the following response headers:
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 2211
Content-Type: image/jpeg
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Date: Fri, 02 Mar 2007 16:27:51 GMT
So for some reason the public isn't making it to the client. At this point it would be nice to get some confirmation from other people that every setup has this behaviour and it's not something particular to our IIS setup (I can't get to that box right now to double-check). WRT the code it looks proper to me. I might suggest adding something like,
Response.Cache.AppendCacheExtension("max-age=86400")
As a first thing to try. Another thing you could look at is to test for the presence of the "If-Modified-Since" header in Request.Headers and spit out a 304 if the timestamp is fairly recent. Another article here on how that can be done pretty easily:
http://www.motobit.com/tips/detpg_net-last-modified/
Another thing would be to try to do a Cache.SetLastModified() to the modified timestamp of the image from the filesystem.
First thing would be to check the headers on other installations though maybe someone will jump in or else hopefully your demo is w/ the most recent version of the module.
|
|
|
|
|
Steve Park
Registered Users
Nuke Active Member
Posts:30
|
| 3/03/2007 11:36 AM |
|
| Actually looks like your own demo has the same behaviour at this point: private & re-sends the images on subsequent page hits... |
|
|
|
|
Scott McCulloch
Administrators
Nuke Master
Posts:12450
|
| 6/11/2008 6:23 AM |
|
| Sorry to resurrect old thread, but these items were resolved quite a while ago. |
|
Scott McCulloch
Site Administrator |
|
|