<div dir="ltr"><div dir="ltr"><div dir="ltr">я не совсем про порты. это скорее был пример, какая документация вспомнилась про эту тему. может и лучше есть.<div><br></div><div><br></div><div>в принципе пасьянс складывается примерно из следующих компонентов (киньте ссылку, если есть готовая документация, сохраню себе)</div><div><br></div><div>1) если вы описываете upstream без keepalive, то соединение закрывается каждый раз</div><div>2) максимальное число запросов в рамках одного соединения до апстрима <a href="https://nginx.org/ru/docs/http/ngx_http_core_module.html#keepalive_requests">Модуль ngx_http_core_module (nginx.org)</a> - если вы пишете тут миллиард, будьте готовы, что на релоаде у вас старые воркеры будут честно пытаться доработать миллиард запросов, и, вероятно, вам придется их гасить через <a href="https://nginx.org/ru/docs/ngx_core_module.html#worker_shutdown_timeout">Основная функциональность (nginx.org)</a> (но эта штука порвет прямо на лету, лучше все таки честно доработать 1000 и аккуратно погасить воркер)</div><div>3) в апстрим есть параметр keepalive, это размер пула поддерживаемых соединений. скажем, вы указали 10, если одновременно уже открыто 5, и все заняты, то открывается еще одно, и после запроса оно добавляется в пул. держать в пуле имеет смысл размер burst-а, на сколько вы можете прирасти запросами. укажете миллиард, будет держать миллиард. смысла, как правило, нет. 5-10 обычно норм</div><div>4) по умолчанию (с отключенным keepalive и на http/1.0), nginx правильно отрабатывает linger-соединения. это когда апстрим закрывает соединение RST, и порт освобождается мгновенно (актуально при reconnect storm-ах). с включенным keepalive порт на стороне nginx отрабатывает в логике, как если бы пришел FIN. может быть больно на штормах</div><div>5) с точки зрения большой картинки, на долговыполняющихся запросах надо аккуратно согласовывать таймауты по всей цепочке- чтобы браузер/ajax ждал дольше, чем nginx, nginx дольше, чем апстрим. это примерно proxy_read_timeout</div><div>6) если у вас в апстриме несколько бекендов, то дефолтный 60-секундный proxy_connect_timeout наверное, неоптимален, можно уменьшать до 5мс (на 100 мегабитной сети RTT менее 1мс)</div><div>7) если бекенды равноправны, то max_fails можно и нужно делать равным нулю. эта настройка предназначена, чтобы на какое-то время внести бекенд в грейлист. если у вас к примеру 1% сетевых потерь, то на относительно невысоком рейте все бекенды кроме последнего будут (не по своей вине) в грейлисте.</div><div><br></div><div>текстом это тяжело воспринимать. буду благодарен, если где-то это уже документировано с картинками и примерами (ну или надо заняться и сделать)</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 25 апр. 2022 г. в 02:31, budarin <<a href="mailto:nginx-forum@forum.nginx.org">nginx-forum@forum.nginx.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">с эфимерными портами все понятно<br>
<br>
вопрос в другом: Nginx имеет настройку keepAliveTimeout для браузера, при<br>
этом он устанавливает соединение с upstream сервером у которого есть свои<br>
настройки keepAliveTimeout - как все это связано между собой? как Nginx<br>
работает с соединениями в upstream (также как браузер с сервером т.е. держит<br>
его до истечения keepAliveTimeout или закрывает его сразу по завершению<br>
запроса)?<br>
<br>
Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?21,294036,294041#msg-294041" rel="noreferrer" target="_blank">https://forum.nginx.org/read.php?21,294036,294041#msg-294041</a><br>
<br>
_______________________________________________<br>
nginx-ru mailing list -- <a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
To unsubscribe send an email to <a href="mailto:nginx-ru-leave@nginx.org" target="_blank">nginx-ru-leave@nginx.org</a><br>
</blockquote></div>