httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: cvs commit: httpd-2.0 STATUS
Date Tue, 12 Nov 2002 15:25:37 GMT wrote:

>   I withdraw this complaint.

>   -    * Rewrite core_output_filter. It is nearly impossible to support
>   -      it with predictable results as it is implemented now.
>   -

Well I think it's predictable now, but not optimal.

For the simplest request I know how to create, it is entered 3 times:
1. HTTP headers
2. file + EOS
3. FLUSH bucket

Driving it 3 times has to cost cycles by itself.  Then for small data, we do 
setasides at #1 and if it's a keepalive connection, again at #2.  Those cost too.

If we haven't seen an EOS or FLUSH yet and the data is too small to send 
immediately, it would be cheaper to just stash the brigade in the context rather 
than doing the setaside at #1.

We should be able to get rid of the FLUSH bucket after EOS for keepalives (and 
the non-blocking socket read syscall which normally gets -1 EAGAIN) by looking 
to see if we have already read extra input data.  If so, then assume it's the 
next request and do the setaside.  If not, then it is unlikely the nonblocking 
read will turn up anything new, so go ahead and write to the network.  For the 
normal case, that would eliminate the setaside at #2 as well as the FLUSH bucket 
and the unproductive read syscall.


View raw message