I think we should leave it alone. This is the difference between benchmarks and the real world. How often do people have 8 requests in a row that total less than 8K?
As a compromise, there are two other options. You could have the core_output_filter refuse to buffer more than 2 requests, or you could have the core_output_filter not buffer if the full request is in the buffer. Removing the buffering is not the correct solution, because it does have a negative impact in the real world. Ryan ---------------------------------------------- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -----Original Message----- > From: Brian Pane [mailto:[EMAIL PROTECTED]] > Sent: Sunday, June 23, 2002 9:38 PM > To: [EMAIL PROTECTED] > Subject: core_output_filter buffering for keepalives? Re: Apache 2.0 > Numbers > > On Sun, 2002-06-23 at 20:58, Brian Pane wrote: > > > For what it's worth, I just tried the test case that you posted. On my > > test system, 2.0 is faster when I run ab without -k, and 1.3 is faster > > when I run with -k. > > I studied this test case and found out why 2.0 runs faster in the > non-keepalive case and slower in the non-keepalive case. It's > because of the logic in core_output_filter() that tries to avoid > small writes when c->keepalive is set. In Rasmus's test, the file > size is only 1KB, so core_output_filter reads in and buffers the > contents of 8 requests before it finally reaches the 8KB threshold > and starts calling writev. 1.3, in contrast, writes out each > request's response immediately, with no buffering. > > I'm somewhat inclined to remove the buffering in this case, and > let core_output_filter send the response as soon as it sees EOS > for each request, even if that means sending a small packet. I > just tried this in my working tree, and it does speed up 2.0 for > this particular test case. On the other hand, I'm not a fan of > small write calls in general. > > Anyone else care to offer an opinion on whether we should remove > the buffering in this situation? > > --Brian >
