httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: AP_MODE_EATCRLF considered indigestible
Date Fri, 15 Apr 2005 15:56:38 GMT
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...

> Removing the mode altogether would mean that either every request was 
> flushed through the filter chain even in pipelining mode, or that 
> ap_process_request would have to come up with some other way of 
> detecting pending input. Unless there is good empirical evidence of the 
> pipelined filter flush leading to performance problems, the first of 
> these options would seem attractive.

I vote for something like your second option but ap_process_request shouldn't be 

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.

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 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 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.


View raw message