[EMAIL PROTECTED] wrote:
I withdraw this complaint.
Well I think it's predictable now, but not optimal.- * Rewrite core_output_filter. It is nearly impossible to support - it with predictable results as it is implemented now. -
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
