Re: limit rate и высокие скорости
Hello! On Thu, Jun 25, 2020 at 03:52:47PM -0400, edo1 wrote: > > https://trac.nginx.org/nginx/ticket/1678#comment:1 > > читал > > > Подкрутить можно размеры буферов и/или включить sendfile, > > размеры крутил (без них было сильно хуже), sendfile тоже пробовал включать > (точнее отключать aio). > > с "output_buffers 2 10m" получается около 80Мб/с, но 20Мб на клиента как-то > перебор (и опять же это не ровно 100, как в указано через limit_rate) Ну так и гигабит на клиента - это немало. Там достаточно простой алгоритм, для ограничения мгновенной скорости считающий время, положенное на отправку конкретного набора буферов. И если погрешности вычислений велики - результат оказывается, скажем так, не идеальным. При скорости в 100 мегабайт в секунду - характерным размером будет 102 килобайта, объём данных, отправляемый за 1 миллисекунду. Суммарный размер буферов меньше - мгновенная скорость ограничиваться не будет. А если больше - то будет, и при типичном значении CONFIG_HZ=250 задержки в 1 миллисекунду будут превращаться в 4 миллисекунды, то есть скорость имеет все шансы оказаться в четыре раза меньше заданной (а если CONFIG_HZ вдруг меньше, как в тикете по ссылке - то будет и того хуже). Погрешность процентов в 10 получим где-то ближе к 4 мегабайтам буферов суммарно, но тут уже скорее всего будут другие ограничивающие факторы - как то особенности шедулинга, размеры буферов сокетов и другие задержки в ходе обработки. Пытаться с этим бороться и напрограммировать алгоритм, не подверженный ошибкам при "плохих" размерах буферов - можно, но смысла в этом не очень много, так как для ограничений в гигабиты limit_rate обычно не используют, AFAIK. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как обработать редирект и проксировать результат приложению?
это не во всех случаях можно сделать корректно. например, 301 по RFC можно отвечать только на GET. а если сервер ответил 301 на POST, какой запрос надо отправить на новый адрес, тоже POST ? или GET ? вот именно этот выбор и доносится до клиента, когда 301 транслируется один в один. теоретически, вы можете накостылить обработчик 301-ошибки, назначить его на локейшен, и в локейшене сделать proxy_pass но это очень скользкая дорожка пт, 26 июн. 2020 г. в 17:41, Александр Карабанов : > Здравствуйте. > > Приложению запрещено самостоятельно открывать соединения с внешним миром. > Приложение отправляет запрос на proxykipalive.lan, а Nginx проксирует этот > запрос на целевой хост (это сделано, чтобы переиспользовать соединение за > счёт keepalive и не открывать новое соединение на каждый запрос от > приложения). > Возникла ситуация, когда целевой хост стал отвечать 301 редиректом, > естественно приложение, получив вместо ожидаемого контента, 301 редирект > сломалось. > Есть ли способ заставить Nginx обработать редирект самостоятельно и отдать > приложению готовый контент? > -- > С уважением, > Александр Карабанов > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Как обработать редирект и проксировать результат приложению?
Здравствуйте. Приложению запрещено самостоятельно открывать соединения с внешним миром. Приложение отправляет запрос на proxykipalive.lan, а Nginx проксирует этот запрос на целевой хост (это сделано, чтобы переиспользовать соединение за счёт keepalive и не открывать новое соединение на каждый запрос от приложения). Возникла ситуация, когда целевой хост стал отвечать 301 редиректом, естественно приложение, получив вместо ожидаемого контента, 301 редирект сломалось. Есть ли способ заставить Nginx обработать редирект самостоятельно и отдать приложению готовый контент? -- С уважением, Александр Карабанов ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
