Closed Bug 72348 Opened 23 years ago Closed 23 years ago

loading pages w/ nonexistant images was slower in 0.8.1 than under 0.8

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: beard, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: perf, regression)

Attachments

(3 files)

Saved HTM page. OnLoad Handler removed.
67.49 KB, text/html
Details
fixes page load delays on attached test case
721 bytes, patch
Details | Diff | Splinter Review
a more general solution
632 bytes, patch
Details | Diff | Splinter Review 
This page is part of the i-bench HTML loading test suite. Under Mozilla 0.8, it 
loads and moves on to the next page almost instantaneously, but under 0.8.1, it 
can take up to 10 seconds or so. This is killing our i-bench numbers.
Keywords: perf
I'm seeing this also. It may be a dup of the other bugs about page loads not 
finishing (or taking a long time to do so), but this needs a real owner...let's 
start with networking.
Assignee: asa → darin
Component: Browser-General → Networking
QA Contact: doronr → tever
Hardware: DEC → All
Keywords: regression
I think this is related to how the server figures out that the page has been 
loaded, so it can time it. I'm not sure, but I imagine that might be some kind of 
onload handler.

Yes, the page has

<BODY onLoad="document.location='pcm-businessnotebooks.htm'" ...>

Evidently this isn't getting fired until some long running computation finishes. 
I don't think it's a networking problem, because the throbber stops, and the 
progress meter shows the document is complete.

Is this assertion relevant?

###!!! ASSERTION: The DocLoader is still busy... There is a bug in End Document 
notifications
: '0', file nsBrowserInstance.cpp, line 998

I take it back, the throbber is still active during this long wait.

I tried running through these tests in a win2k trunk build today. I was 
actually stopping a few pages earlier than this one, on the second cycle 
of the test, although hitting reload I could nudge the browser forward until
finally this page, where onload would never fire. 

This may be only coincidence (and a moot point soon with a new cache 
implementation), but I had started with a new cache, and noticed that I started
failing when the cache was close to the 512 limit. By either manually deleting 
the cache entries, or manually surfing until the cache blew itself away, and 
then returning to a URL near the end of the first cycle, I found that I could 
get the browser to continue past the pages where it was getting stuck. I could 
repeat this (start fresh, stall, get cache blown away, then I could continue).
Also, see the end of bug 39310, which I closed in favour of other specific
bugs (the meaning of bug 39310 had become overloaded in my opinion). There
I list a variety of bugs that involve pages that do not finish loading.
Blocks: 71668
Darin, any news?  Drivers are looking hard at this for 0.8.1.

/be
Patrick and I are working on this...
Darin, what's the status on this one. Any chance of a fix this morning?
I haven't been able to track this down yet.  I'm focused on other things,
so I'm not sure when I'll be able to spend more time on this.
I don't think that this is *all* a networking problem.  I saved the page off to
disk and removed the OnLoad handler.  The page still takes ~6 second to render
(so the status bar sayz).  

I will attached the page.


Maybe someone in layout should look at this.
URL: http://i-bench.zdnet.com/ibench/perfo...
also, this render time is about the same as what 4.x does.
marc, do you have a spare cycle to take a look at this bug?
We seem to be taking forever to deal with an image not being on the server.  My
mozilla build took 53 seconds to give up on loading the images in
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=28278
Note that I'm using a squid cache, though that shouldn't make any real
difference.
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9
I've narrowed this down to the fact that for 404 image responses, gfx
returns NS_ERROR_ABORT in response to OnStartRequest.  OnStartRequest
is called from nsHTTPServerListener::OnDataAvailable when the response
headers are completely available.  NS_ERROR_ABORT is passed to the
caller of nsHTTPServerListener::OnDataAvailable which is nsStreamObserverProxy.
The stack ends there since this is a proxied event.

The problem is that the socket transport is never canceled in this case.

I'm not sure when or how this regressed... seems like we should have always
had this bug.  hmmm... investigating.

Ah, nsHTTPResponseListener.cpp, darin's and my favorite warren-code.

There are severalf early returns (usually of the warren-style 'if
(NS_FAILED(rv))return rv;') in that function, in other response code cases, and
earlier.  Should any of these also cancel the request?

/be
brendan: good point... and i see now that this would explain some of the slow
down when processing many redirects.  notice that rv=NS_BINDING_ABORTED for
redirects... there is no explicit Cancel on the socket transport.

I'm going to go away and fix this function for real!

    
    

    
  
It occured to me that the correct fix for this problem really lies in 
nsStreamListenerProxy.cpp... that is, it should really cancel the underlying
request whenever OnDataAvailable returns an unexpected failure code.

This should be correct thing in all cases when nsStreamListenerProxy is used.

    
  
Keywords: patch

    
    

    
  
dougt says: "r/sr=dougt on the new patch"

    
    

    
  
fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
*** Bug 71180 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 70531 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 71653 has been marked as a duplicate of this bug. ***

    
    

    
  
verified:
WinNT4 2001052204
Linux rh6 2001052213
Mac os9 2001051504
Status: RESOLVED → VERIFIED

    
    

    
  
Is this bug really fixed?

I'm working on a intranet page with a very large collection of server generated 
hidden input fields.
Earlier versions of Netscape (6.01) and Mozilla had the same problem but in the 
meantime it differs somehow.

The behaviour before:
On the first load of the page everything is alright.
If I submit the form to the server and the page is newly generated the 
rendering will be interrupted and e.g. any JS-alert at the end of the page will 
be ignored.
If I submit the form once more there will be everything alright again (failing 
every second time).
With the earlier Versions of Mozilla/Netscape the onload event was thrown when 
the bug appeared. So I could get the length of the input fields collection by 
an onload alert (which was to small). 
Viewing of the Source resubmits the form and so in the sourcecode everything is 
as it should be. If I save this sourcecode, the page load's and reload's 
without faults but that doesn't solve my problems.
There may be a server problem too, but Netscape should be possible to handle it 
(like MSIExplorer does).
I failed to generate a small example page wihtout our intranet setting.
I noticed that this bug does not appear on an Apache Server but only on IIS

The behaviour of the latest browser versions differs in one point:
The bug is still there but the onload event isn't thrown. (Netscape 6.1pr1 and 
Mozilla 9.1+[20010620]).



    
    

    
  
yes, this bug had a specific problem (I think my summary change is correct) and 
a specific solution. it also had a specific version interval.  If you have 
complaints about page load times please file a new bug (or find another 
currently open bug, i bet there are plenty to choose from).
URL: http://bugzilla.mozilla.org/showattac...
Summary: Page load performance slower in 0.8.1 than under 0.8 → loading pages w/ nonexistant images was slower in 0.8.1 than under 0.8

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: