Re: Modification to mod_fastcgi

[email protected] wrote:
 > So we propose a quite primitive modification to mod_fastcgi:
 > We added a routine to fcgi_protocol.c which tries to figure out
 > if the end of request protocol blocks are completely contained
 > in the data read from the FCGI server.
 > We added a block to the routine socket_io before the call to
 > ap_select. This block calls the newly added routine. If this
 > call finds the end of request protocol blocks, ap_select is
 > called with a very small timeout value and no timeout error
 > is delivered if ap_select returns with a timeout for this call.

Unfortunately this fix doesn't solve the symptom we've seen that's caused by the
same problem. The core problem is that data can get stuck in the
serverInputBuffer until the server process sends more data if the 
clientOutputBuffer is empty. You see it as a request time out but in our 
streaming application it manifests as data sending delays.

I think the general solution is to check the serverInputBuffer before doing the
ap_select call and if there is data there and the clientOutputBuffer is not full 
then do the ap_select call with a zero timeout instead of the usual timeout. 
This will prevent data from getting stuck in the serverInputBuffer. If the 
clientOutputBuffer is full then the timeouts should be set as normal (if this 
isn't done then slow clients will cause high server load as mod_fastcgi 
repeatedly attempts to move the data across).

This should fix both our problems.

Thanks.

-- 
Hayden

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/