default HTTP buffer size is too small

RESOLVED FIXED in mozilla1.3beta

Status

()

Core
Networking: HTTP
P3
normal
RESOLVED FIXED
16 years ago
15 years ago

People

(Reporter: Darin Fisher, Assigned: Darin Fisher)

Tracking

({perf})

Trunk
mozilla1.3beta
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

16 years ago
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.
(Assignee)

Comment 1

16 years ago
Created attachment 100374 [details] [diff] [review]
v1 patch
(Assignee)

Comment 2

16 years ago
Created attachment 100376 [details] [diff] [review]
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.
(Assignee)

Comment 3

16 years ago
Comment on attachment 100374 [details] [diff] [review]
v1 patch

duplicate post
Attachment #100374 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Keywords: mozilla1.2, nsbeta1, perf
Priority: -- → P3
Target Milestone: --- → mozilla1.2beta
*** Bug 170595 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 5

16 years ago
Comment on attachment 100376 [details] [diff] [review]
v1 patch

this patch has thread synchonization issues.
Attachment #100376 - Flags: needs-work+
(Assignee)

Comment 6

16 years ago
-> moz 1.3
Target Milestone: mozilla1.2beta → mozilla1.3alpha
(Assignee)

Updated

15 years ago
Target Milestone: mozilla1.3alpha → mozilla1.3beta
(Assignee)

Comment 7

15 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.