я сознательно опустил моменты, описанные в ephemeral ports exhaustion. в большой картине мира с кипэлайвами, та часть документации тоже имеет значение
пн, 25 апр. 2022 г. в 10:09, Илья Шипицин <chipits...@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-fo...@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-le...@nginx.org >> >
_______________________________________________ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
