Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-24 Пенетрантность Валентин Бартенев 
On Tuesday 24 May 2016 12:26:22 S.A.N wrote:
> > > 
> > > Даже в РНР появляются новые асинхронные фрейворки, не говоря уже про
> > > Node.js, Go, etc..
> > > Возможно уже пришло время, переосмыслить и переписать логику работы
> > > upstream
> > > в Nginx?
> > > Тогда асинхронные бекенды смогут эффективней работать.
> > > 
> > 
> > Асинхронный nginx прекрасно работает по HTTP/1.x сам с собой, так
> > какие проблемы
> > возникают у перечисленных фреймворков?
> > 
> 
> Мы уже ходим по кругу :), я уже писал, что браузеры в реальной жизни часто
> отправляют множество запросов в одном соединении, в результате все эти
> запросы становятся в очередь к бекенду, вместо параллельного выполнения,
> вообще браузеры одновременно более 4-8 соединений не открывают, давайте
> говорить честно, Nginx выполняет запросы HTTP/1.x в одном соединении
> последовательно, а не асинхронно.

Какой браузер отправляет в одном HTTP/1.1 соединении следующий запрос не
дожидаясь ответа на предыдущий?

Ещё раз, если речь идет об общении между бэкендом и nginx, то nginx так
не делает, он использует столько соединений, сколько необходимо обработать
запросов и ни один запрос не ждет в очереди.  Ситуация браузер <-> сервер,
и сервер <-> бэкенд - они разные, не нужно их мешать в одну кучу.

Проблема, которую решает HTTP/2 возникает только между браузером и сервером,
и только потому, что браузер по RFC ограничен в количестве TCP соединений.

Когда такого ограничения нет, то HTTP/1 с одним запросом на соединение
работает лучше и эффективнее.


> 
> Кстати nodejs/http-parser уже планируют реализовать HTTP/2, так что спрос на
> мультиплексирования запросов к бекенду, будет только расти.
> 

Что совершенно не делает HTTP/2 лучшим выбором при общении с бэкендом.

Мультиплексирование запросов к бекенду есть и без HTTP/2, на уровне TCP,
и HTTP/2 тут только лишний оверхэд создает.  Подозреваю, что уже для
1000 запросов оверхэд может стать весьма заметным.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

[nginx-ru-announce] nginx-1.11.0

2016-05-24 Пенетрантность Maxim Dounin 
Изменения в nginx 1.11.0  24.05.2016

*) Добавление: параметр transparent директив proxy_bind, fastcgi_bind,
   memcached_bind, scgi_bind и uwsgi_bind.

*) Добавление: переменная $request_id.

*) Добавление: директива map поддерживает комбинации нескольких
   переменных в качестве результирующих значений.

*) Добавление: теперь при использовании метода epoll nginx проверяет,
   поддерживает ли ядро события EPOLLRDHUP, и соответственно
   оптимизирует обработку соединений.

*) Добавление: директивы ssl_certificate и ssl_certificate_key теперь
   можно указывать несколько раз для загрузки сертификатов разных типов
   (например, RSA и ECDSA).

*) Добавление: при использовании OpenSSL 1.0.2 и новее с помощью
   директивы ssl_ecdh_curve теперь можно задать список кривых; по
   умолчанию используется встроенный в OpenSSL список кривых.

*) Изменение: для использования DHE-шифров теперь надо явно задавать
   файл параметров с помощью директивы ssl_dhparam.

*) Добавление: переменная $proxy_protocol_port.

*) Добавление: переменная $realip_remote_port в модуле
   ngx_http_realip_module.

*) Добавление: модуль ngx_http_realip_module теперь позволяет
   устанавливать не только адрес, но и порт клиента.

*) Изменение: при попытке запросить виртуальный сервер, отличающийся от
   согласованного в процессе SSL handshake, теперь возвращается ответ
   "421 Misdirected Request"; это улучшает совместимость с некоторыми
   HTTP/2-клиентами в случае использования клиентских сертификатов.

*) Изменение: HTTP/2-клиенты теперь могут сразу присылать тело запроса;
   директива http2_body_preread_size позволяет указать размер буфера,
   который будет использоваться до того, как nginx начнёт читать тело.

*) Исправление: при использовании директивы proxy_cache_bypass не
   обновлялись закэшированные ошибочные ответы.


-- 
Maxim Dounin
http://nginx.org/

___
nginx-ru-announce mailing list
nginx-ru-announce@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru-announce

nginx-1.11.0

2016-05-24 Пенетрантность Maxim Dounin 
Изменения в nginx 1.11.0  24.05.2016

*) Добавление: параметр transparent директив proxy_bind, fastcgi_bind,
   memcached_bind, scgi_bind и uwsgi_bind.

*) Добавление: переменная $request_id.

*) Добавление: директива map поддерживает комбинации нескольких
   переменных в качестве результирующих значений.

*) Добавление: теперь при использовании метода epoll nginx проверяет,
   поддерживает ли ядро события EPOLLRDHUP, и соответственно
   оптимизирует обработку соединений.

*) Добавление: директивы ssl_certificate и ssl_certificate_key теперь
   можно указывать несколько раз для загрузки сертификатов разных типов
   (например, RSA и ECDSA).

*) Добавление: при использовании OpenSSL 1.0.2 и новее с помощью
   директивы ssl_ecdh_curve теперь можно задать список кривых; по
   умолчанию используется встроенный в OpenSSL список кривых.

*) Изменение: для использования DHE-шифров теперь надо явно задавать
   файл параметров с помощью директивы ssl_dhparam.

*) Добавление: переменная $proxy_protocol_port.

*) Добавление: переменная $realip_remote_port в модуле
   ngx_http_realip_module.

*) Добавление: модуль ngx_http_realip_module теперь позволяет
   устанавливать не только адрес, но и порт клиента.

*) Изменение: при попытке запросить виртуальный сервер, отличающийся от
   согласованного в процессе SSL handshake, теперь возвращается ответ
   "421 Misdirected Request"; это улучшает совместимость с некоторыми
   HTTP/2-клиентами в случае использования клиентских сертификатов.

*) Изменение: HTTP/2-клиенты теперь могут сразу присылать тело запроса;
   директива http2_body_preread_size позволяет указать размер буфера,
   который будет использоваться до того, как nginx начнёт читать тело.

*) Исправление: при использовании директивы proxy_cache_bypass не
   обновлялись закэшированные ошибочные ответы.


-- 
Maxim Dounin
http://nginx.org/

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-24 Пенетрантность Evgeniy Berdnikov 
On Tue, May 24, 2016 at 08:34:57AM -0400, S.A.N wrote:
> Протокол клиента HTTP/1.1 все три запроса браузер отправляет в одном
> конекте.
> Nginx отправляет все эти три запроса в одном конекте на бекенд.
> 
> Теперь смотрим как все плохо в HTTP/1.1 когда в одном конекте приходит
> очередь HTTP запросов, допустим время ответа у нас такое:
> 
> GET /one HTTP/1.1 -- 500ms
> GET /two HTTP/1.1 -- 20ms
> GET /three HTTP/1.1 -- 10ms
> 
> Бекенд многопоточный, он бы мог принять и обработать второй и третий запрос,
> не дожидаясь обработки первого медленного запроса.

 В принципе да, Nginx мог бы обрабатывать эти запросы параллельно. Не знаю,
 делает он так или нет, но ответы всё равно придётся отдавать в сеть
 последовательно: в HTTP/1.1 есть лишь pipelining, который подразумевает
 сериализацию ответов, но нет мультиплексирования, которое позволило бы
 переставлять ответы местами и/или выдавать по частям.
-- 
 Eugene Berdnikov

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-24 Пенетрантность Vasiliy P. Melnik 
reuseport не поможет?

24 мая 2016 г., 17:49 пользователь Валентин Бартенев 
написал:

> On Tuesday 24 May 2016 10:38:46 S.A.N wrote:
> > > > Nginx никогда не посылает запрос в то же соединение, пока не
> > > получит
> > > > ответ
> > > > и соединение освободиться.  Т.н. pipelining он не умеет и не
> > > > использует.
> > > >
> > > > Если бы следующий запрос пришел до того, как на первый был получен
> > > > ответ,
> > > > то он бы был отправлен на бекенд в другом соединении.
> > > >
> > > > Т.е. никакой проблемы между nginx и бекендом нет.
> > >
> > > Да, конечно Nginx не пошлет второй и третий запрос на бекенд, пока
> > > первый не ответит, в этом и проблема, потому что он ждет ответа на
> > > первый запрос, я бы ещё понял если бы Nginx не ждал ответа на первый
> > > запрос и отправил второй и третий запрос в другом свободном конекте
> > > или открыл новый конект, но Nginx эти запросы будет держать в очереди
> > > и это очень плохо.
> > > Могу выслать код теста.
> > >
> >
> > Я ещё раз проверил, Nginx разносит три запроса из одного клиенского
> > соеденения, по разным соединениям бекенда только если клиент сделал
> запросы
> > по протоколу HTTP/2, если клиент сделает эти три запроса по протоколу
> > HTTP/1.1, тогда Nginx никогда не разносит запросы из одного клиентского
> > соединения по разным соединениям бекенда.
> >
> [..]
>
> Всё верно, потому что запросы в одном соединении по протоколу HTTP/1.1
> обрабатываются последовательно.
>
> Если вы хотите сделать три параллельных запроса в HTTP/1.1, то для этого
> нужно отрыть 3 соединения и в каждом делать по запросу.
>
> --
> Валентин Бартенев
> ___
> 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

Re: Зависание nginx из-за memcached

2016-05-24 Пенетрантность Vadim Osipov 
Yuriy Medvedev Wrote:
---
> UP: посмотрел как у вас собран nginx и если не вы rpm билдили, тогда
> это
> стандартный пакет для rhel подобных

Ну, если бы я не собирал rpm с помощью rpmbuild, не включал бы сторонние
модули, то да это был бы стандартным пакет rhel, который можно скачать из
http://nginx.org/packages/centos/6/x86_64/RPMS/ и да, вы были бы правы.

А к чему мы об этом ? Вы намекаете на то, чтобы протестировать только те
locations, которые не используют директивы сторонних модулей, удалив заодно
сами директивы и попытаться дать нагрузку на стандартный пакет версии 1.4.2
?

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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-24 Пенетрантность Валентин Бартенев 
On Tuesday 24 May 2016 10:38:46 S.A.N wrote:
> > > Nginx никогда не посылает запрос в то же соединение, пока не
> > получит
> > > ответ
> > > и соединение освободиться.  Т.н. pipelining он не умеет и не
> > > использует.
> > > 
> > > Если бы следующий запрос пришел до того, как на первый был получен
> > > ответ,
> > > то он бы был отправлен на бекенд в другом соединении.
> > > 
> > > Т.е. никакой проблемы между nginx и бекендом нет.
> > 
> > Да, конечно Nginx не пошлет второй и третий запрос на бекенд, пока
> > первый не ответит, в этом и проблема, потому что он ждет ответа на
> > первый запрос, я бы ещё понял если бы Nginx не ждал ответа на первый
> > запрос и отправил второй и третий запрос в другом свободном конекте
> > или открыл новый конект, но Nginx эти запросы будет держать в очереди
> > и это очень плохо.
> > Могу выслать код теста.
> > 
> 
> Я ещё раз проверил, Nginx разносит три запроса из одного клиенского
> соеденения, по разным соединениям бекенда только если клиент сделал запросы
> по протоколу HTTP/2, если клиент сделает эти три запроса по протоколу
> HTTP/1.1, тогда Nginx никогда не разносит запросы из одного клиентского
> соединения по разным соединениям бекенда.
> 
[..]

Всё верно, потому что запросы в одном соединении по протоколу HTTP/1.1
обрабатываются последовательно.

Если вы хотите сделать три параллельных запроса в HTTP/1.1, то для этого
нужно отрыть 3 соединения и в каждом делать по запросу.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-24 Пенетрантность S.A.N 
> > Nginx никогда не посылает запрос в то же соединение, пока не
> получит
> > ответ
> > и соединение освободиться.  Т.н. pipelining он не умеет и не
> > использует.
> > 
> > Если бы следующий запрос пришел до того, как на первый был получен
> > ответ,
> > то он бы был отправлен на бекенд в другом соединении.
> > 
> > Т.е. никакой проблемы между nginx и бекендом нет.
> 
> Да, конечно Nginx не пошлет второй и третий запрос на бекенд, пока
> первый не ответит, в этом и проблема, потому что он ждет ответа на
> первый запрос, я бы ещё понял если бы Nginx не ждал ответа на первый
> запрос и отправил второй и третий запрос в другом свободном конекте
> или открыл новый конект, но Nginx эти запросы будет держать в очереди
> и это очень плохо.
> Могу выслать код теста.
> 

Я ещё раз проверил, Nginx разносит три запроса из одного клиенского
соеденения, по разным соединениям бекенда только если клиент сделал запросы
по протоколу HTTP/2, если клиент сделает эти три запроса по протоколу
HTTP/1.1, тогда Nginx никогда не разносит запросы из одного клиентского
соединения по разным соединениям бекенда.

Проверил на Nginx/1.9.15 без стороних модулей.
Я здесь выложу исходники тест скриптов, они не большие и результат, я
тестировал в nc чтобы убедится что все три запроса отправляются в одном
соединение.

В роли бекенда может быть все что угодно, главное чтобы бекенд умел
принимать и паралейно выполнять новые соеденения, даже FPM с тремя воркерами
подойдет.

Три РНР скрипта:

-- 1.php
--
https://forum.nginx.org/read.php?21,266693,267096#msg-267096

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-24 Пенетрантность Валентин Бартенев 
On Tuesday 24 May 2016 08:57:46 S.A.N wrote:
> > Nginx никогда не посылает запрос в то же соединение, пока не получит
> > ответ и соединение освободиться.  Т.н. pipelining он не умеет и не
> > использует.
> > 
> > Если бы следующий запрос пришел до того, как на первый был получен
> > ответ, то он бы был отправлен на бекенд в другом соединении.
> > 
> > Т.е. никакой проблемы между nginx и бекендом нет.
> 
> Да, конечно Nginx не пошлет второй и третий запрос на бекенд, пока первый не
> ответит, в этом и проблема, потому что он ждет ответа на первый запрос, я бы
> ещё понял если бы Nginx не ждал ответа на первый запрос и отправил второй и
> третий запрос в другом свободном конекте или открыл новый конект, но Nginx
> эти запросы будет держать в очереди и это очень плохо.
> Могу выслать код теста.
> 

Вышлите.  Текущая версия nginx без сторонних модулей ждать не умеет, и чтобы
научить его ждать в Plus даже специальную очередь программировать пришлось.


> 
> > Проблема в общении браузера и сервера, которую решает
> > мультиплексирование,
> > заключается исключительно в том, что браузер жестко ограничен в
> > количестве TCP
> > соединений.
> 
> > Между nginx и бекендом - такого ограничения нет, следовательно и
> > проблемы тоже.
> 
> В линуксе кол-во открытых fd тоже ограничено.
> 

Равно как и память в системе, которую HTTP/2 будет кушать.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Зависание nginx из-за memcached

2016-05-24 Пенетрантность Vadim A. Misbakh-Soloviov 
> почему порядок имеет значение - не дошли руки разобраться еще.
Для модулей NginX (особенно связанных с filter-инфраструктурой) это довольно 
обычное явление. Например, для модулей, использующих модуль ndk как "базу" 
такое очень свойственно. Для naxsi. Ну и т.п.

Особенности архитектуры NginX, в общем :)

// а учитывая декларативный характер конфига — с динамическими модулями 
проблема тоже сохраняется. Только прееносится из "какой первым добавить в 
сборку" на "какой первым объявить в конфиге" :) 

-- 
wbr,
mva
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-24 Пенетрантность S.A.N 
> Вы просто перенесете то, что реализовано в ядре операционной системы
> внутрь приложения.  В случае HTTP/2 у вас будет на каждый отдельный
> запрос свой внутренний идентификатор со своими накладными расходами,
> который точно также будет "простаивать" пока запрос обрабатывается.
> 
> У вас уже есть мультиплексирование на уровне TCP/IP.
> 
> HTTP/2 - это коробочка в коробочке.


Провел простые тесты, получил интересные результаты.

Браузер делает три аякс запроса

GET /one HTTP/1.1
GET /two HTTP/1.1
GET /three HTTP/1.1

Протокол клиента HTTP/1.1 все три запроса браузер отправляет в одном
конекте.
Nginx отправляет все эти три запроса в одном конекте на бекенд.

Теперь смотрим как все плохо в HTTP/1.1 когда в одном конекте приходит
очередь HTTP запросов, допустим время ответа у нас такое:

GET /one HTTP/1.1 -- 500ms
GET /two HTTP/1.1 -- 20ms
GET /three HTTP/1.1 -- 10ms

Бекенд многопоточный, он бы мог принять и обработать второй и третий запрос,
не дожидаясь обработки первого медленного запроса.

Есть три варианта как это сделать:

1. Бекенд читает все запросы из сокета и обрабатывает асинхроно, ответы
буферизирует чтобы отправить в том же порядки как пришли запросы.

2. Перейти на НТТР/2 для работы бекенда с Nginx, но этого нет в планах
Nginx

3. Если сделать свой велосипед, использовать $request_id для связи ответов и
запросов, тогда бекенд сможет отвечать асинхроно, будет в зоголовке
указывать $request_id запроса на который он отвечает, Nginx клиенту отправит
ответы в той же последовательности как клиент прислал запросы.


Я не люблю велосипеды ($request_id) но если Nginx не планирует
мультиплескирования (НТТР/2 или FastCGI) в апстримах, возможно это неплохой
компромис, как вы считаете?

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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Зависание nginx из-за memcached

2016-05-24 Пенетрантность Михаил Монашёв 
Здравствуйте, Vadim.

> просмотрел  Release  notes  от  1.4.2  и  выше и какого упоминания о
> исправлении возможного бага в коде модуля memcached не заметил.

Сторонние модули могут наводить проблемы для других модулей. Чем их
меньше, тем лучше.

А обновиться стоит потому, что несколько secure-багов исправлено.

-- 
С уважением,
 Михаил  mailto:postmas...@softsearch.ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Зависание nginx из-за memcached

2016-05-24 Пенетрантность Yuriy Medvedev 
UP: посмотрел как у вас собран nginx и если не вы rpm билдили, тогда это
стандартный пакет для rhel подобных

24 мая 2016 г., 11:21 пользователь Yuriy Medvedev 
написал:

> Вы для бинарных дистрибутивов из исходных кодов собираете?
>
> 24 мая 2016 г., 10:27 пользователь Vadim Osipov <
> nginx-fo...@forum.nginx.org> написал:
>
> Извините, в каком смысле собрать пакет ? :) Последней версии nginx ?
>> Ну, чтобы показать, что он решает проблему возможных ошибок в коде, нужно
>> воспроизвести проблему на старом решении. Просто, возможно, проблема с
>> конфигурацией.
>>
>> P.S.
>> Я тесты с killall -11 еще не проводил, но чувствую, что придется
>> надеяться,
>> что 1.10 решит проблему, хотя просмотрел Release notes от 1.4.2 и выше и
>> какого упоминания о исправлении возможного бага в коде модуля memcached не
>> заметил.
>>
>> Posted at Nginx Forum:
>> https://forum.nginx.org/read.php?21,267049,267078#msg-267078
>>
>> ___
>> 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

Re: Зависание nginx из-за memcached

2016-05-24 Пенетрантность Yuriy Medvedev 
Вы для бинарных дистрибутивов из исходных кодов собираете?

24 мая 2016 г., 10:27 пользователь Vadim Osipov  написал:

> Извините, в каком смысле собрать пакет ? :) Последней версии nginx ?
> Ну, чтобы показать, что он решает проблему возможных ошибок в коде, нужно
> воспроизвести проблему на старом решении. Просто, возможно, проблема с
> конфигурацией.
>
> P.S.
> Я тесты с killall -11 еще не проводил, но чувствую, что придется надеяться,
> что 1.10 решит проблему, хотя просмотрел Release notes от 1.4.2 и выше и
> какого упоминания о исправлении возможного бага в коде модуля memcached не
> заметил.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,267049,267078#msg-267078
>
> ___
> 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

Re: Зависание nginx из-за memcached

2016-05-24 Пенетрантность Vadim Osipov 
h264, flv, mp4 - все это можно безболезненно убрать (есть выделенные
видеосервера). Использование h264, возможно, - legacy, пытались снизить
нагрузку с видеосерверов, точно не знаю.

Push модуль точно нужен, используем его для организации comet-соединений.

Из советов по проблеме, все-таки решил собрать 1.10 (хотя руководству не
очень нравится идея обычного и нагрузочного тестирования), там и убрал часть
сторонних модулей (осталось только заменить на эквиваленты, появившееся в
самом nginx). Ориентировочно так выглядит часть описания из configure:
--without-http_fastcgi_module \
--without-http_uwsgi_module \
--without-http_scgi_module \
--without-http_ssi_module \
--without-http_empty_gif_module \
--with-http_ssl_module \
--with-http_realip_module \
--with-http_sub_module \
--with-http_gunzip_module \
--with-http_gzip_static_module \
--with-http_stub_status_module \
--with-http_xslt_module=dynamic \
--with-http_image_filter_module=dynamic \
--with-http_geoip_module=dynamic \
--with-http_perl_module=dynamic \
--add-dynamic-module=njs-%{module_njs_shaid}/nginx \
--with-threads \
--with-stream \
--with-stream_ssl_module \
--with-http_slice_module \
--with-file-aio \
--with-ipv6 \
--add-module=nginx-push-stream-module-0.5.1 \
--add-module=headers-more-nginx-module-0.29 \
--add-module=echo-nginx-module-0.58 \

А скажите, как вы обнаружили, что в вашем случае проблема была в
headers-more-nginx-module ? Добавили модуль и через какое то короткое время
и/или через access & error logs увидели, что после прихода запрос на какой
то url возникает зависание ?

+ вы полностью от headers-more-nginx-module отказались, заменив на связку
add_header + убрав возможное дублирование заголовка со стороны application
server ?

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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru