stoddard@apache.org 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.
Greg
|