FastCGI Client Hangs on Requests to Overloaded PHP-FastCGI server

Erik Osterman <[email protected]>
Newsgroups gmane.comp.web.fastcgi.devel
Message-ID <[email protected]>
I've developed a FastCGI class to interface with a php-fastcgi server 
(php 5.2). My problem might be with PHP's implementation of FastCGI, in 
which case I realize I'm on the wrong list. Before I file a bug report 
with PHP, however, I want to make sure that I'm not doing anything wrong 
as far as the protocol is concerned.

Overall, the client interaction works fine. My problem is that if open 
up more than connections than PHP_FCGI_CHILDREN on the php fcgi server, 
then the additional connections don't function properly. All the 
connections get accepted just fine; I can send requests down the pipe 
and there are no errors. But selecting from the pipe, I never get any 
data back... I poll forever. I would expect that the fcgi server would 
drop the connections, not accept them at all or respond with 
FCGI_OVERLOADED, if the server maxed out. What actually happens, though, 
is if I set PHP_FCGI_CHILDREN to 1, open up 3 client connections and 
send 100 requests (round-robin style), then 66% fail. If I change 
PHP_FCGI_CHILDREN to 2 and send 100 RR requests, then 33% fail and so 
on. Thus, what's happening is pretty clear.

1. What could I do to detect this error? (asside from timeouts)

Clearly, I realize I can just increase PHP_FCGI_CHILDREN and if I do, my 
problems go away. I'm setting it very low is just to debug/illustrate 
this problem. In our case, it is not a viable solution, however, to just 
increase the number of children since at any given time we can run out. 
We need our clients to detect if a server will process the request or 
not. We cannot afford to constantly rely on timeouts. If a FastCGI 
server's connections are maxed out, we need to have our client connect 
to another fcgi server. The protocol provides for FCGI_GET_VALUES, which 
will return FCGI_MAX_CONNS, but this really isn't very useful if you 
have multiple different clients connecting to the same FastCGI server. 
The clients would have to negotiate b/w themselves as to how to allocate 
the slots and this seems messy.

2. Is the problem with the PHP server? Should it respond with 
FCGI_OVERLOADED, drop the connection, or just not accept it to begin with?

3. Is anyone else doing something similar and not having issues?

Best Regards,

Erik Osterman
___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.