keepalive connection to fastcgi backend hangs
mdounin at mdounin.ru
Mon Dec 20 19:35:36 UTC 2021
On Mon, Dec 20, 2021 at 04:00:59PM +0000, Nicolas Franck wrote:
> 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
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.
More information about the nginx