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/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx