On Fri, Apr 15, 2005 at 11:56:38AM -0400, Greg Ames wrote: > Rici Lake wrote: > >I was taking a look at the implementation of the renamed (but still > >misleading) AP_MODE_EATCRLF, > > AP_MODE_PEEK was more accurate, but whatever...
No, it certainly wasn't, but let's not re-open old wounds. ;-) > the reason that this and the corresponding 1.3 BUFF logic exists is to > minimize "tinygrams" - ip packets that are less than a full mtu size. > tinygrams definately degrade network performance and trigger things like > Nagle's algorithm. in this particular case we are trying to combine > response data from two or more different pipelined requests into a single > packet. I'm not sure this optimization is really necessary any more. It seems overly complicated given that most responses span multiple IP packets. And, we specifically disabled Nagle anyway. > however our post-filters implementation is very costly in terms of cpu. we > make an extra trip down both filter chains. on the first trip down the > output filter chain we are almost ready to call apr to transmit the data > when the core output filter stashes the output data, temporarily abandons > it, and unwinds. then we go down the input filter chain with This will happen for anything less than AP_MIN_BYTES_TO_WRITE anyway. > AP_MODE_EAT_CRLF to see if there is more input data stashed (and do an > extra socket read() syscall that doesn't happen in 1.3). assuming the > answer is no (typical) we send a flush bucket down the output filter chain, > get back to the core output filter, encounter numerous cache misses reading > all the instructions and data back into the cpu caches to pick up where we > left off, then finally hand off the response data to the apr socket > functions. > > what I'd like to see instead is for the input filter chain to keep track of > whether there is any stashed input any time it is called. then the core There's no real way to do that across all filters. (Nor should there be, IMHO.) > output filter could do a simple check on the first trip down the output > filter chain to see whether it's ok to transmit. the downside is that we > may have accumulated extra baggage that is dependent on AP_MODE_EAT_CRLF or > flush buckets, so this change would definately need to wait for a version > boundary. in the mean time we should avoid adding any new function > dependent on AP_MODE_EAT_CRLF or standalone flush buckets. Dorky idea: we could move the pipeline ready check to the if EOS clause in ap_pass_brigade where we mark eos_sent. If there is no data ready (via a speculative read: I see no way to not do that), then we add the flush bucket. We'd also take out that EOS check for the deferred writes in core_output_filter as we're doing the check earlier on. So, by the time we hit core_output_filter, we already know if we should hang on to the connection. This would save us from the extra round trip. I'm not sure where else we could even place such a check besides ap_pass_brigade. -- justin
