On Tuesday 24 May 2016 12:26:22 S.A.N wrote:
> > >
> > > Даже в РНР появляются новые асинхронные фрейворки, не говоря уже про
> > > Node.js, Go, etc..
> > > Возможно уже пришло время, переосмыслить и переписать логику работы
> > > upstream
> > > в Nginx?
> > > Тогда асинхронные бекенды смогут эффе
Изменения в nginx 1.11.0 24.05.2016
*) Добавление: параметр transparent директив proxy_bind, fastcgi_bind,
memcached_bind, scgi_bind и uwsgi_bind.
*) Добавление: переменная $request_id.
*) Добавление: директива map поддерживает комбинац
> >
> > Даже в РНР появляются новые асинхронные фрейворки, не говоря уже про
> > Node.js, Go, etc..
> > Возможно уже пришло время, переосмыслить и переписать логику работы
> upstream
> > в Nginx?
> > Тогда асинхронные бекенды смогут эффективней работать.
> >
>
> Асинхронный nginx прекрасно работ
Михаил Монашёв Wrote:
---
> Здравствуйте, Vadim.
>
> > просмотрел Release notes от 1.4.2 и выше и какого упоминания о
> > исправлении возможного бага в коде модуля memcached не заметил.
>
> Сторонние модули могут наводить проблемы для друг
On Tuesday 24 May 2016 11:20:58 S.A.N wrote:
> > Всё верно, потому что запросы в одном соединении по протоколу HTTP/1.1
> > обрабатываются последовательно.
> >
> > Если вы хотите сделать три параллельных запроса в HTTP/1.1, то для
> > этого
> > нужно отрыть 3 соединения и в каждом делать по запрос
On Tuesday 24 May 2016 18:13:14 Vasiliy P. Melnik wrote:
> reuseport не поможет?
>
[..]
SO_REUSEPORT к этому не имеет вообще никакого отношения.
Проблема тут искусственно создана с помощью теста, который
отправляет три запроса в одном соединении.
Подробнее про reuseport тут:
https://habrahabr.r
> Всё верно, потому что запросы в одном соединении по протоколу HTTP/1.1
> обрабатываются последовательно.
>
> Если вы хотите сделать три параллельных запроса в HTTP/1.1, то для
> этого
> нужно отрыть 3 соединения и в каждом делать по запросу.
В этом то и проблема, браузеры на НТТР/1.1 часто экон
On Tue, May 24, 2016 at 08:34:57AM -0400, S.A.N wrote:
> Протокол клиента HTTP/1.1 все три запроса браузер отправляет в одном
> конекте.
> Nginx отправляет все эти три запроса в одном конекте на бекенд.
>
> Теперь смотрим как все плохо в HTTP/1.1 когда в одном конекте приходит
> очередь HTTP запро
reuseport не поможет?
24 мая 2016 г., 17:49 пользователь Валентин Бартенев
написал:
> On Tuesday 24 May 2016 10:38:46 S.A.N wrote:
> > > > Nginx никогда не посылает запрос в то же соединение, пока не
> > > получит
> > > > ответ
> > > > и соединение освободиться. Т.н. pipelining он не умеет и не
On Tuesday 24 May 2016 03:22:20 Vadim Osipov wrote:
> h264, flv, mp4 - все это можно безболезненно убрать (есть выделенные
> видеосервера). Использование h264, возможно, - legacy, пытались снизить
> нагрузку с видеосерверов, точно не знаю.
>
> Push модуль точно нужен, используем его для организаци
Yuriy Medvedev Wrote:
---
> UP: посмотрел как у вас собран nginx и если не вы rpm билдили, тогда
> это
> стандартный пакет для rhel подобных
Ну, если бы я не собирал rpm с помощью rpmbuild, не включал бы сторонние
модули, то да это был бы стандар
On Tuesday 24 May 2016 10:38:46 S.A.N wrote:
> > > Nginx никогда не посылает запрос в то же соединение, пока не
> > получит
> > > ответ
> > > и соединение освободиться. Т.н. pipelining он не умеет и не
> > > использует.
> > >
> > > Если бы следующий запрос пришел до того, как на первый был получе
> > Nginx никогда не посылает запрос в то же соединение, пока не
> получит
> > ответ
> > и соединение освободиться. Т.н. pipelining он не умеет и не
> > использует.
> >
> > Если бы следующий запрос пришел до того, как на первый был получен
> > ответ,
> > то он бы был отправлен на бекенд в другом
On Tuesday 24 May 2016 08:57:46 S.A.N wrote:
> > Nginx никогда не посылает запрос в то же соединение, пока не получит
> > ответ и соединение освободиться. Т.н. pipelining он не умеет и не
> > использует.
> >
> > Если бы следующий запрос пришел до того, как на первый был получен
> > ответ, то он б
у меня не очень укладывается в голове, что он втихую это обрабатывает.
сругался бы чтоли. не должно это быть обычным явлением
дойдут руки, посмотрю
24 мая 2016 г., 17:35 пользователь Vadim A. Misbakh-Soloviov написал:
> > почему порядок имеет значение - не дошли руки разобраться еще.
> Для моду
> Nginx никогда не посылает запрос в то же соединение, пока не получит
> ответ
> и соединение освободиться. Т.н. pipelining он не умеет и не
> использует.
>
> Если бы следующий запрос пришел до того, как на первый был получен
> ответ,
> то он бы был отправлен на бекенд в другом соединении.
>
> Т
On Tuesday 24 May 2016 08:34:57 S.A.N wrote:
> > Вы просто перенесете то, что реализовано в ядре операционной системы
> > внутрь приложения. В случае HTTP/2 у вас будет на каждый отдельный
> > запрос свой внутренний идентификатор со своими накладными расходами,
> > который точно также будет "прост
> почему порядок имеет значение - не дошли руки разобраться еще.
Для модулей NginX (особенно связанных с filter-инфраструктурой) это довольно
обычное явление. Например, для модулей, использующих модуль ndk как "базу"
такое очень свойственно. Для naxsi. Ну и т.п.
Особенности архитектуры NginX, в
> Вы просто перенесете то, что реализовано в ядре операционной системы
> внутрь приложения. В случае HTTP/2 у вас будет на каждый отдельный
> запрос свой внутренний идентификатор со своими накладными расходами,
> который точно также будет "простаивать" пока запрос обрабатывается.
>
> У вас уже ес
экспериментально обнаружили. был модуль - были зависания, не было модуля -
не было зависаний. это давно было, модуль выпилили, глубже копать не стали.
на add_header не получалось, оно на 500-е коды в то время не умело
добавлять.
насчет вашей текущей ситуации, если добавлять модули в том порядке, в
Здравствуйте, Vadim.
> просмотрел Release notes от 1.4.2 и выше и какого упоминания о
> исправлении возможного бага в коде модуля memcached не заметил.
Сторонние модули могут наводить проблемы для других модулей. Чем их
меньше, тем лучше.
А обновиться стоит потому, что несколько secure-баг
UP: посмотрел как у вас собран nginx и если не вы rpm билдили, тогда это
стандартный пакет для rhel подобных
24 мая 2016 г., 11:21 пользователь Yuriy Medvedev
написал:
> Вы для бинарных дистрибутивов из исходных кодов собираете?
>
> 24 мая 2016 г., 10:27 пользователь Vadim Osipov <
> nginx-fo...
Вы для бинарных дистрибутивов из исходных кодов собираете?
24 мая 2016 г., 10:27 пользователь Vadim Osipov написал:
> Извините, в каком смысле собрать пакет ? :) Последней версии nginx ?
> Ну, чтобы показать, что он решает проблему возможных ошибок в коде, нужно
> воспроизвести проблему на старо
Извините, в каком смысле собрать пакет ? :) Последней версии nginx ?
Ну, чтобы показать, что он решает проблему возможных ошибок в коде, нужно
воспроизвести проблему на старом решении. Просто, возможно, проблема с
конфигурацией.
P.S.
Я тесты с killall -11 еще не проводил, но чувствую, что придетс
h264, flv, mp4 - все это можно безболезненно убрать (есть выделенные
видеосервера). Использование h264, возможно, - legacy, пытались снизить
нагрузку с видеосерверов, точно не знаю.
Push модуль точно нужен, используем его для организации comet-соединений.
Из советов по проблеме, все-таки решил со
25 matches
Mail list logo
