[Moscow.pm] nginx-perl prerelease 1.1.6.1

[Ruslan Zakirov]

2011/11/13 Alexandr Gomoliako <zzz на zzz.org.ua>:
> On 11/13/11, Ruslan Zakirov <ruz на bestpractical.com> wrote:
>> Какой в этом смысл тогда? Чем это будет отличаться от других серверов?
>> Тогда одно отличие, что можно послать асинхронно запрос, что-то
>> поделать.
>
> Да, только асинхронностью и отличается.
> Если блокироваться внутри, то это как префорк сервер с возможностью
> выполнять что-то в перерывах между запросами. Это даже будет чуть-чуть
> быстрее, чем типичный префорк сервер, но это не так важно.

Выгода конечно есть.

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

Я говорил про любые БД, а не только DBI. У Тима Банса спрашивал о том
когда появится асинхронный API в DBI, на что был получен ответ, что
как только DBD драйвера отполирую частные решения, то можно будит
говорить про унификацию. Это было два года назад.

> Некоторые выносят 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. Кто-то хочет этим заняться? :)

Я посмотрел внутренности краем глаза. Мне показалось, что можно
написать биндинги к абстракции Nginx, который тоже работает на куче
решений, но расскрыть доступ к дескрипторам, которые так или иначе там
сохраняются, но это только показалось.

> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards, Ruslan.