170469 - default HTTP buffer size is too small

Status: RESOLVED FIXED

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

Description

[Darin Fisher]

i was looking at some tcpdumps the other day, and i noticed something very odd.
 while loading the www.nytimes.com off of the ginger version of cowtools over
the LAN at work, i noticed that the TCP windowsize on the client was going to
zero, causing significant delays in the retrieval of the toplevel HTML page. 
sort of like stop-and-go traffic.  the server sends data while the client's
advertised window size is non-zero.  if it goes to zero, then the server must
wait for the client to send an ACK signaling a non-zero window.  well, that
requires layout to get off its butt! ;-)

in my test of ginger/www.nytimes.com, the toplevel page takes roughly 325 ms to
load out of a total of 647 for the entire page.  however, when i increased the
networking buffer sizes from 16k to 64k, i was able to reduce the load time for
the toplevel page down to ~130 ms.  this savings doesn't entirely translate to
overall load time, but i did notice ~100ms savings (~15%), which isn't too
shabby ;-)

i repeated my tests over DSL, but i found that in this case the larger buffer
sizes do not help.  it seems layout is fast enough to consume the data (at least
that's the case w/ my 850MHz laptop).  i imagine modem tests will show the same
result.

in the past, i tried increasing the same buffers, but found no such improvement.
 i have suspicious ranging from the fact that our campus network recently got
upgraded to the possibility that i may have done those tests before HTTP was
fully able to process transactions on a background thread.

at any rate, this seems like a really cheap way to squeeze some more Tp out of
mozilla... at least over a LAN connection anyways.  also, www.nytimes.com isn't
exactly the most representative site.  i need to run this patch through the
entire page loader to see how well this modification helps overall.

Comment 1

[Darin Fisher]

Attachment: v1 patch

Comment 2

[Darin Fisher]

Attachment: v1 patch

this patch increases the HTTP max buffer size from 16k to 64k (still allocated
in 4k segments on demand).  in addition, i've modified nsStreamListenerProxy to
report OnDataAvailable events no larger than 16k.  this keeps necko from
slamming its consumers too hard ;-)

i probably have to do a bit of work on this patch to expose the rather
arbitrary 16k OnDataAvailable chunking size via nsIStreamListenerProxy.

Comment 3

[Darin Fisher]

Comment on attachment 100374 [details] [diff] [review]
v1 patch

duplicate post

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Darin Fisher]

Comment on attachment 100376 [details] [diff] [review]
v1 patch

this patch has thread synchonization issues.

Comment 6

[Darin Fisher]

-> moz 1.3

Comment 7

[Darin Fisher]

fixed as a result of the patch for bug 176919 landing.  default buffer size is
now 4096 x 16.  max ODA size remains at 16k for necko consumers.