On Wed, 2001-11-21 at 10:14, Ryan Bloom wrote: > On Tuesday 20 November 2001 03:23 pm, Doug MacEachern wrote: > > Okay, I have looked at this again. I have a patch, but it is doing too much > buffering now. :-( I'm hoping to fix this soon. However, there is a > misunderstanding in the question below that I want to clear up. We try > to buffer up to AP_MIN_BYTES_TO_WRITE in the core, never more than > that. With that logic, the behavior you are seeing is correct. However, > you are seeing the correct behavior because of the values that you chose. > :-) > Hey Ryan. while your looking at buffering is there any way to buffer the stuff up over brigades? mod-include creates a seperate brigade per virtual include and you can get lots of small packets being sent
> If you use > > GET /test?20,500 > > You will see two writes, one for 476, and one for 200. That is incorrect. > > Ryan > > > can someone explain how the core output buffering is supposed to work? > > if you look at > > httpd-test/perl-framework/c-modules/test_pass_brigade/mod_test_pass_brigade > >.c this intentionally creates a brigade with just one bucket and calls > > ap_pass_brigade with that bucket. you can make a request like so: > > http://localhost:8529/test_pass_brigade?1024,500000 > > which means use a buffer size of 1024 bytes and send 500k total. > > with the patch below for tracing i see this in the error_log: > > writev 15543 bytes > > writev 16384 bytes > > writev 10240 bytes > > writev 8192 bytes > > ... a bunch of 8192's ... > > writev 7456 bytes > > writev 0 bytes > > > > then with 8192,500000: > > writev 41143 bytes > > writev 8192 bytes > > ... a bunch of 8192's ... > > writev 288 bytes > > writev 0 bytes > > > > is this the expected behavior? reason i am asking is that mod_ssl pretty > > much does what mod_test_pass_brigade.c does with 8192 size buffers. i > > have a patch in the works to optimize that, but want to make sure core > > output filter is behaving as expected first. i thought it would buffer > > until it could fill AP_MIN_BYTES_TO_WRITE * MAX_IOVEC_TO_WRITE. but then > > again, i guess there is a reason it doesn't, since the OLD_WRITE filter > > does its own buffering. insight greatly appreciated, thanks. > > > > p.s. > > i realize the answer is probably buried in the archives, maybe somebody > > wants to write a documented summary? > > > > --- server/core.c 2001/11/19 22:36:20 1.100 > > +++ server/core.c 2001/11/20 22:52:56 > > @@ -3201,7 +3201,7 @@ > > } > > else { > > apr_size_t unused_bytes_sent; > > - > > + fprintf(stderr, "writev %d bytes\n", nbytes); > > rv = writev_it_all(net->client_socket, > > vec, nvec, > > nbytes, &unused_bytes_sent); > > -- > > ______________________________________________________________ > Ryan Bloom [EMAIL PROTECTED] > Covalent Technologies [EMAIL PROTECTED] > -------------------------------------------------------------- -- Ian Holsman [EMAIL PROTECTED] Performance Measurement & Analysis CNET Networks - (415) 344-2608
