57773 - Pages load 30% slower than needed, redundant GET of IMG

Status: VERIFIED DUPLICATE of bug 57730

(Core :: Networking: Cache, defect, P3)

Description

[John Morrison]

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 ...].

Comment 1

[John Morrison]

I should add that for modem/dial-up users, this slowdown would, in all 
likelihood, be much greater, given the latency/bandwidth difference.

Comment 2

[Gagan]

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.

Comment 3

[gabriel]

I'm voting for this already...

Comment 4

[Tomi Leppikangas]

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.

Comment 5

[John Morrison]

Attachment: tar.gz of the two test files, plus images, for those of you playing from home

Comment 6

[pnunn]

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

Comment 7

[gordon]

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-.

Comment 8

[John Morrison]

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.

Comment 9

[selmer (gone)]

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.

Comment 10

[pnunn]

marking as a dupe of 57730

*** This bug has been marked as a duplicate of 57730 ***

Comment 11

[John Morrison]

yep.