httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: AP_MODE_EATCRLF considered indigestible
Date Fri, 15 Apr 2005 17:09:39 GMT
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

Mime
View raw message