<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
I kind of agree: keepalive connections are not strictly necessary in this scenario.<br class="">
<br class="">
But there is a reason why I started looking into this: I started noticing a lot<br class="">
of closed tcp connections with status TIME_WAIT. That happens when you<br class="">
close the connection on your end, and the os keeps these around for a few<br class="">
seconds, to make sure that the other end of the connection got the tcp "FIN".<br class="">
During that time the client port for that connection cannot be used:<br class="">
<br class="">
$ netstat -an | grep :5000<br class="">
<br class="">
(if the fcgi app is listening on port 5000)<br class="">
<br class="">
If you receive a lot of requests after each other, and the number grows<br class="">
larger than the os can free the TIME_WAIT connections, then you'll run<br class="">
out of client ports, and see seemingly unrelated errors like "dns lookup failure".<br class="">
This even happens when the response of the upstream server is fast, as it<br class="">
takes a "lot" of time before the TIME_WAIT connections are freed.<br class="">
<br class="">
Reuse of tcp connections is one way to tackle this problem.<br class="">
Playing around with sysctl is another:<br class="">
<br class="">
$ sysctl -w net.ipv4.tcp_tw_recycle=1<br class="">
<br class="">
But I am not well versed in this, and I do not know a lot<br class="">
about the possible side effects.<br class="">
<br class="">
cf. <a href="https://web3us.com/drupal6/how-guides/what-timewait-state" class="">https://web3us.com/drupal6/how-guides/what-timewait-state</a>
<div class="">cf. <a href="https://onlinehelp.opswat.com/centralmgmt/What_you_need_to_do_if_you_see_too_many_TIME_WAIT_sockets.html" class="">https://onlinehelp.opswat.com/centralmgmt/What_you_need_to_do_if_you_see_too_many_TIME_WAIT_sockets.html</a></div>
<div class=""><br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On 20 Dec 2021, at 20:35, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" class="">mdounin@mdounin.ru</a>> wrote:<br class="">
<br class="">
Hello!<br class="">
<br class="">
On Mon, Dec 20, 2021 at 04:00:59PM +0000, Nicolas Franck wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Interesting!<br class="">
<br class="">
I looks like there is nothing that managing the incoming connections<br class="">
for the fcgi workers. Every fcgi worker needs to do this on its own, right?<br class="">
So if there are more clients (i.e. nginx workers) than fcgi workers,<br class="">
then it becomes unresponsive after a few requests, because all<br class="">
the fcgi workers are holding on to a connection to an nginx worker,<br class="">
and there seems to be no queue handling this. <br class="">
<br class="">
Is this correct? Just guessing here<br class="">
</blockquote>
<br class="">
More or less. The FastCGI code in your example implies very <br class="">
simple connection management, based on the process-per-connection <br class="">
model. As long as all FastCGI processes are busy, all additional <br class="">
connections will be queued in the listen queue of FastCGI <br class="">
listening socket (till a connection is closed). Certainly that's <br class="">
not the only model possible with FastCGI, but the easiest to use.<br class="">
<br class="">
The process-per-connection model doesn't combine well with <br class="">
keepalive connections, since each keepalive connection occupies <br class="">
the whole process. And you have to create enough processes to <br class="">
handle all keepalive connections you want to be able to keep <br class="">
alive. In case of nginx as a client, this means at least (<number <br class="">
of connections in the keepalive directive> * <number of worker <br class="">
processes>) processes.<br class="">
<br class="">
Alternatively, you can avoid using keepalive connections. These <br class="">
are not really needed for local upstream servers, since connection <br class="">
establishment costs are usually negligible compared to the total <br class="">
request processing costs. And this is what nginx does by default.<br class="">
<br class="">
-- <br class="">
Maxim Dounin<br class="">
<a href="https://eur03.safelinks.protection.outlook.com/?" class="">https://eur03.safelinks.protection.outlook.com/?</a>url=http%3A%2F%2Fmdounin.ru%2F&data=04%7C01%7CNicolas.Franck%40ugent.be%7Cb8a3cee984e84e47f86408d9c3efed9f%7Cd7811cdeecef496c8f91a1786241b99c%7C1%7C0%7C637756257522060451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FSv4njqodduc7rpTd5m0FXnO1DBmQooZmFXABzKbC2A%3D&reserved=0<br class="">
_______________________________________________<br class="">
nginx mailing list<br class="">
nginx@nginx.org<br class="">
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.nginx.org%2Fmailman%2Flistinfo%2Fnginx&data=04%7C01%7CNicolas.Franck%40ugent.be%7Cb8a3cee984e84e47f86408d9c3efed9f%7Cd7811cdeecef496c8f91a1786241b99c%7C1%7C0%7C637756257522060451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3gI9%2F8oxIPl65YD1pbdE5zT%2FsUM7JQUW5qLkQpSCAGU%3D&reserved=0<br class="">
</blockquote>
<br class="">
</div>
</body>
</html>