Re: keepAliveTimeout для Nginx и для сервера в upstream

[Илья Шипицин]

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

пн, 25 апр. 2022 г. в 10:09, Илья Шипицин <chipitsine на gmail.com>:

> я не совсем про порты. это скорее был пример, какая документация
> вспомнилась про эту тему. может и лучше есть.
>
>
> в принципе пасьянс складывается примерно из следующих компонентов (киньте
> ссылку, если есть готовая документация, сохраню себе)
>
> 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
>>
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20220425/3ebf3eec/attachment.htm>