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.
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.
Comment on attachment 100374 [details] [diff] [review] v1 patch duplicate post
Attachment #100374 - Attachment is obsolete: true
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. ***
Comment on attachment 100376 [details] [diff] [review] v1 patch this patch has thread synchonization issues.
Attachment #100376 - Flags: needs-work+
-> moz 1.3
Target Milestone: mozilla1.2beta → mozilla1.3alpha
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: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.