я не совсем про порты. это скорее был пример, какая документация
вспомнилась про эту тему. может и лучше есть.


в принципе пасьянс складывается примерно из следующих компонентов (киньте
ссылку, если есть готовая документация, сохраню себе)

1) если вы описываете upstream без keepalive, то соединение закрывается
каждый раз
2) максимальное число запросов в рамках одного соединения до апстрима Модуль
ngx_http_core_module (nginx.org)
<https://nginx.org/ru/docs/http/ngx_http_core_module.html#keepalive_requests> -
если вы пишете тут миллиард, будьте готовы, что на релоаде у вас старые
воркеры будут честно пытаться доработать миллиард запросов, и, вероятно,
вам придется их гасить через Основная функциональность (nginx.org)
<https://nginx.org/ru/docs/ngx_core_module.html#worker_shutdown_timeout> (но
эта штука порвет прямо на лету, лучше все таки честно доработать 1000 и
аккуратно погасить воркер)
3) в апстрим есть параметр keepalive, это размер пула поддерживаемых
соединений. скажем, вы указали 10, если одновременно уже открыто 5, и все
заняты, то открывается еще одно, и после запроса оно добавляется в пул.
держать в пуле имеет смысл размер burst-а, на сколько вы можете прирасти
запросами. укажете миллиард, будет держать миллиард. смысла, как правило,
нет. 5-10 обычно норм
4) по умолчанию (с отключенным keepalive и на http/1.0), nginx правильно
отрабатывает linger-соединения. это когда апстрим закрывает соединение RST,
и порт освобождается мгновенно (актуально при reconnect storm-ах). с
включенным keepalive порт на стороне nginx отрабатывает в логике, как если
бы пришел FIN. может быть больно на штормах
5) с точки зрения большой картинки, на долговыполняющихся запросах надо
аккуратно согласовывать таймауты по всей цепочке- чтобы браузер/ajax ждал
дольше, чем nginx, nginx дольше, чем апстрим. это примерно
proxy_read_timeout
6) если у вас в апстриме несколько бекендов, то дефолтный 60-секундный
proxy_connect_timeout наверное, неоптимален, можно уменьшать до 5мс (на 100
мегабитной сети RTT менее 1мс)
7) если бекенды равноправны, то max_fails можно и нужно делать равным нулю.
эта настройка предназначена, чтобы на какое-то время внести бекенд в
грейлист. если у вас к примеру 1% сетевых потерь, то на относительно
невысоком рейте все бекенды кроме последнего будут (не по своей вине) в
грейлисте.

текстом это тяжело воспринимать. буду благодарен, если где-то это уже
документировано с картинками и примерами (ну или надо заняться и сделать)

пн, 25 апр. 2022 г. в 02:31, budarin <nginx-forum@forum.nginx.org>:

> с эфимерными портами все понятно
>
> вопрос в другом: Nginx имеет настройку keepAliveTimeout для браузера, при
> этом он устанавливает соединение с upstream сервером у которого есть свои
> настройки keepAliveTimeout - как все это связано между собой? как Nginx
> работает с соединениями в upstream (также как браузер с сервером т.е.
> держит
> его до истечения keepAliveTimeout или закрывает его сразу по завершению
> запроса)?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,294036,294041#msg-294041
>
> _______________________________________________
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-leave@nginx.org
>
_______________________________________________
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-leave@nginx.org