74.64 KB, application/octet-stream
While doing some testing for bug 56599, I noticed that independent of the 'First time' vs. 'Every Time' setting, on an initial visit to a test page, some images were being requested multiple times. I mentioned this to pnunn, and she suggested that it might be related to image sizes. I analyzed a test replica of home.netscape.com, and I found that this was the case: For each unique WIDTH/HEIGHT/VSPACE/HSPACE for 'foo.gif', the same URL will be requested an additional time. Since "professional web sites" very commonly will use "pixel.gif" and stretch it multiple different ways in a page to achieve control of the positioning of text, etc. this is a very common real-world slowdown. Test Pages: There are two facsimiles of http://home.netscape.com/, including a copy of all images, at http://jrgm.mcom.com/adhoc/time-to-load/multiple-server-hits/test.html http://jrgm.mcom.com/adhoc/time-to-load/multiple-server-hits/testx.html 'test.html' -- is identical to http://home.netscape.com/, including local copies of the images, so I can check the logs. 'testx.html' -- as above, but certain IMG HEIGHT and WIDTH modified to avoid additional GET requests to the Apache server. The key difference is that 'test.html', on a first visit to the page, will generate 18 redundant HTTP GET -- requests for the same image triggered by a difference in the size parameters. Build Tested: Branch MN6 2000102309 -- win2k -- 500MHz, 128MB, Netscape LAN. Server: Apache/1.3.9 (Red Hat/Linux 6.1) Time Trials: 1) shutdown and delete the cache folder. (Profile is set to check 'Once per session', but with a clean cache, that means the first time. If this were set to 'Every time', with the patch for bug 56599 not in the build, then this extra cost would be paid every time the site was visited). 2) startup (new cache created), go to home.netscape.com as home page, shutdown 3) startup, go to home.netscape.com, then to either of the test pages (remember the images are not cached on the first visit). test.html testx.html (18 redundant GET) (0 redundant GET) 1 - 2219 1656 2 - 2000 1734 3 - 2125 1516 4 - 2172 1672 5 - 2187 1765 6 - 2140 1532 7 - 2094 1750 Avg. - 2134 1661 So, in this example, we are 1.28 times as slow going to the home page due to the redundant GET requests. Please tell me there is a Santa Claus, and that this is just some 'slip of a boolean'. [Marking rtm, but ...].
I should add that for modem/dial-up users, this slowdown would, in all likelihood, be much greater, given the latency/bandwidth difference.
ouch this looks really bad. (and is quite similar to what you(pam) were talking about in the PDT meeting today) ->pnunn Unless we can have a small/low risk fix this will probably have to be an rtm- But I'd let Pam think about this.
Assignee: gagan → pnunn
I'm voting for this already...
Maybe this is related: 1. Go to www.slashdot.org 2. scroll bottom of page 3. hit reload 3. see green line starting to blink and mozilla sucking cpu, image is reloaded over and over from net. Different network prefs didnt make difference. This is quite bad since it generates network load, could easily kill server.
Created attachment 17887 [details] tar.gz of the two test files, plus images, for those of you playing from home
We _should_ be getting the compressed image data from the necko cache, since imglib caches decompressed&sized images. It looks like necko doesn't know the specifics of the request, sees the VALIDATE-EVERY attribute and sends a ping to the server (304). Some how we need to tell necko that the request belongs to the same page (load group), which is fresh and therefore the necko cache version is "fresh enough". I'll take a look, but this looks like a candidate for the next train, not the one leaving the station. -p
Status: NEW → ASSIGNED
Pam, the initial description states this is independent of the VALIDATE_ALWAYS attribute. Are we actually requesting the images multiple times, or are we just checking modification dates? For small images these are both equally bad, but knowing which case is occuring will help track down the source of the problem. I'd want to see a potential fix before labeling this bug rtm-.
The server logs show that the response is a 304 Not Modified, so I presume the request is a If-Modified-Since. I could turn on logging if more detail would help in narrowing this down.
Is this being worked on? If so, please put [rtm need info] in the whiteboard. If there isn't a small, safe fix already in hand, this is probably missing the train. Please update the whiteboard either way.
Whiteboard: [need info]
marking as a dupe of 57730 *** This bug has been marked as a duplicate of 57730 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.