keepalive connection to fastcgi backend hangs

[Maxim Dounin]

Hello!

On Mon, Dec 20, 2021 at 04:00:59PM +0000, Nicolas Franck wrote:

> Interesting!
> 
> I looks like there is nothing that managing the incoming connections
> for the fcgi workers. Every fcgi worker needs to do this on its own, right?
> So if there are more clients (i.e. nginx workers) than fcgi workers,
> then it becomes unresponsive after a few requests, because all
> the fcgi workers are holding on to a connection to an nginx worker,
> and there seems to be no queue handling this. 
> 
> Is this correct? Just guessing here

More or less.  The FastCGI code in your example implies very 
simple connection management, based on the process-per-connection 
model.  As long as all FastCGI processes are busy, all additional 
connections will be queued in the listen queue of FastCGI 
listening socket (till a connection is closed).  Certainly that's 
not the only model possible with FastCGI, but the easiest to use.

The process-per-connection model doesn't combine well with 
keepalive connections, since each keepalive connection occupies 
the whole process.  And you have to create enough processes to 
handle all keepalive connections you want to be able to keep 
alive.  In case of nginx as a client, this means at least (<number 
of connections in the keepalive directive> * <number of worker 
processes>) processes.

Alternatively, you can avoid using keepalive connections.  These 
are not really needed for local upstream servers, since connection 
establishment costs are usually negligible compared to the total 
request processing costs.  And this is what nginx does by default.

-- 
Maxim Dounin
http://mdounin.ru/