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

2022-04-26 Пенетрантность budarin 
Ух! забористо :)

спасибо за подробное описание - правда я, как чайник, сразу все не осилю:
скажу что сложности в понимании и настройки keepAlive для связки
браузер-nginx-гupstreams стало больше

Хорошо бы если было бы описание на примере разбора и установки параметров
для всей цепочки

Со стороны браузера хотелось бы разумного keepAlive, а на бэкэнде хочется
равномерного распределения нагрузки между всеми хостами в апстриме без
удержания постоянных соединений 

Был бы очень благодарен за разбор на примере - можно было бы оформить потом
в статью чтобы было полезно всем  - я думаю многие с этим сталкиваются но
мало кто реально понимает и правильно настраивает такую связку для
keepAlive
Тема нигде толком не освещена - перечитал весь интернет

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,294036,294053#msg-294053

___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

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

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

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

> я не совсем про порты. это скорее был пример, какая документация
> вспомнилась про эту тему. может и лучше есть.
>
>
> в принципе пасьянс складывается примерно из следующих компонентов (киньте
> ссылку, если есть готовая документация, сохраню себе)
>
> 1) если вы описываете upstream без keepalive, то соединение закрывается
> каждый раз
> 2) максимальное число запросов в рамках одного соединения до апстрима Модуль
> ngx_http_core_module (nginx.org)
>  
> -
> если вы пишете тут миллиард, будьте готовы, что на релоаде у вас старые
> воркеры будут честно пытаться доработать миллиард запросов, и, вероятно,
> вам придется их гасить через Основная функциональность (nginx.org)
>  (но
> эта штука порвет прямо на лету, лучше все таки честно доработать 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 имеет настройку 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-le...@nginx.org
>>
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

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

2022-04-24 Пенетрантность Илья Шипицин 
я не совсем про порты. это скорее был пример, какая документация
вспомнилась про эту тему. может и лучше есть.


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

1) если вы описываете upstream без keepalive, то соединение закрывается
каждый раз
2) максимальное число запросов в рамках одного соединения до апстрима Модуль
ngx_http_core_module (nginx.org)
 -
если вы пишете тут миллиард, будьте готовы, что на релоаде у вас старые
воркеры будут честно пытаться доработать миллиард запросов, и, вероятно,
вам придется их гасить через Основная функциональность (nginx.org)
 (но
эта штука порвет прямо на лету, лучше все таки честно доработать 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 имеет настройку 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-le...@nginx.org
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

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

2022-04-24 Пенетрантность budarin 
с эфимерными портами все понятно

вопрос в другом: 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-le...@nginx.org

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

2022-04-23 Пенетрантность Илья Шипицин 
можно начать с Overcoming Ephemeral Port Exhaustion in NGINX Plus


вс, 24 апр. 2022 г. в 03:57, budarin :

> Добрый день!
>
> Хотелось бы понять суть и установить верные значения keepAliveTimeout как
> для Nginx так и для серверов в upstream.
>
> Каково вообще оптимальное значение этого параметра для клиента в браузере
> для обычного web-приложения в Nginx?
>
> Удерживает ли Nginx alive соединение с серверами в upstream?
>
> Какими должны быть эти значения чтобы оптимально
> - держать открытыми только "живые соединения" и оперативно закрывать не
> активные чтобы не держать кучу соединений
> - оптимально позволять загружать запросами инстансы в upstream
>
> если Nginx не держит постоянного соединения с конкретным upstream, то
> понятно что параметр keepAliveTimeout в инстансе сервиса должен быть
> минимальным чтобы Nginx мог равномерно распределить нагрузку между
> несколькими серверами upstream
>
> если же Nginx держит постоянное соединение с сервером upstream то насколько
> я понимаю параметр keepAliveTimeout у них должен быть одинаковым?
>
> или может не париться и держать все соединения живыми максимально долго?
>
> Проясните пожалуйста ситуацию.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,294036,294036#msg-294036
>
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org