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