[Moscow.pm] nginx-perl prerelease 1.1.6.1

[Alexandr Gomoliako]

On 11/13/11, Ruslan Zakirov <ruz at bestpractical.com> wrote:
> Какой в этом смысл тогда? Чем это будет отличаться от других серверов?
> Тогда одно отличие, что можно послать асинхронно запрос, что-то
> поделать.

Да, только асинхронностью и отличается.
Если блокироваться внутри, то это как префорк сервер с возможностью
выполнять что-то в перерывах между запросами. Это даже будет чуть-чуть
быстрее, чем типичный префорк сервер, но это не так важно.

Типичные задачи могут быть:
  - что-то распределенное, т.е. когда нужно постоянно проверять состояние
    нод, отправлять запросы на две ноды сразу (quorum logic),
    синхронизироваться с другими нодами и т.д.;
  - когда нужно минимизировать время отклика, тоже отправлять
    на пару нод сразу и отдавать ответ клиенту сразу после первого ответа;
  - когда нужно много работать с внешними интернет ресурсами;
  - работа по HTTP с современными nosql базами данных;

А вообще любое приложение может выиграть в производительности,
но стоит ли оно того, это другой вопрос.

> Плохо, что блокируют. В современном веб приложении общаемся больше
> всего с БД, а все остальное обработка текста и преобразование
> полученых данных. Блокировать общение с БД тоже самое, что превратить
> событийный сервер в форкающийся. Какими же такими плюсами обладает
> такое решение, что дажее блокируя его все равно мы остаемся в плюсе.

Тут проблема не в серверах, а в DBI. Он никогда не станет неблокирующим.

Некоторые выносят DBI в отдельный процесс, модуль Марка по-моему так
делает. Можно точно так же запустить отдельный nginx и создать простенький
JSON интерфейс для работы с DBI, как я когда-то уже предлагал.
А к уже нему подключаться асинхронно из другого. Это тоже самое.

Но это проблемы не решает, DBI как блокировался, так и блокируется,
просто в другом процессе. Но так как клиенты обычно распределены
во времени, то они точно так же ждут ответа от DBI.

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

> Было бы интересно получить AE приложение, которое работает совместно с
> nginx loop'ом и периодически передают друг другу управление. То есть
> должно быть неважно использую ли я ngx соединения с чем-то еще или
> AE'шные соединения. Не знаю возможно ли такое в принципе поиметь с API
> nginx. Что скажете?

> Хочется AE, потому что есть готовые решения для различных задач,
> переносимость, работа кода за пределами веб сервера.

Теоретически это возможно, но только теоретически.
Т.е. если реализовать libev event module для nginx, то можно будет
запускать AE внутри nginx. Но скорее всего будут проблемы, потому
что в nginx куча макросов по всему коду для kqueue и edge/level triggering
для epoll. Кто-то хочет этим заняться? :)