Bugzilla – Bug 1319
Images Not Cached in SS Web Interface - Performance
Last modified: 2008-08-18 10:54:16 UTC
I've noticed that the SlimServer web interfaces seem to reload the images on each refresh. That is, they seem to go back to the HTTP server for the images rather than load them from the browser's local cache. This is bound to be causing unnecessary load on the server. It's not a lot of work, but it is a flurry of HTTP requests coming in at once. And given that some performance issues in serving streams seem to correlate with usage of the web interfaces, I thought this might be worth a look. S/W Config: Server: SS6.0.0, WinXPsp2, server password is set Client: Firefox 1.0.2, LiveHTTPHeaders, Win2000 I used the LiveHTTPHeaders extension for Firefox. This allows me to see and record the HTTP request/responses exchanges in realtime. I loaded a playlist, connected a player and let the stream run. Waited for an automatic refresh of the web UI. The result was pretty standard, except for the image requests, which looked like this: http://myserver:9000/html/images/spacer.gif GET /html/images/spacer.gif HTTP/1.1 Host: myserver:9000 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Accept: image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://myserver:9000/status_header.html?player=129.0.0.1&start=&refresh=1 Authorization: Basic obscured== Pragma: no-cache Cache-Control: no-cache HTTP/1.x 200 OK Cache-Control: public; max-age=15552000 Connection: keep-alive Date: Wed, 06 Apr 2005 16:23:12 GMT Content-Length: 43 Content-Type: image/gif Expires: Mon, 03 Oct 2005 16:23:12 GMT Last-Modified: Mon, 28 Mar 2005 18:52:50 GMT The HTTP request portion is mostly OK. What raises questions are the Pragma: no-cache and Cache-Control: no-cache headers. Pragma is mostly a legacy setting that may affect caching proxies. Cache-Control would seem to be directing the browser to _never_ hold a copy of the image data in cache. The HTTP response section indicates what looks to be a correct Last-Modified date and a nice long time to it's Expires date. This makes it look like the intention is to cache these images. If image caching is desired, there may be a non-trivial performance gain to be had.
Ron - I've commited code that you've seen on the dev list, along with my ETag changes. Please see subversion change 3283 for more detail.
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!