[Moscow.pm] процессы и AnyEvent: быстрая передача данных

[Ruslan Zakirov]

2011/1/13 Ivan Petrov <i.petro.77.00 на gmail.com>:
>
>> Поделите  обработку  на несколько очень мелких по времени работы фаз и
>> после  обработки  каждой  фазы  возвращайте управление в AnyEvent. Так
>> решает подобную задачу тот же nginx.
>
> Хороший путь но не всегда рабочий.
>
> я отдаю вебстранички. как в любой системе получается несколько стадий:
> выборка направления движения-обработки (контроллер), выборка данных
> (модель),  выдача данных (отображение). На более мелкие фазы как-то не
> бъется.
>
> то есть если например идет сборка html из темплейта то ее уже сложно побить,
> разве что свой темплейтный адаптер ваять.


Если идет сборка HTML из шаблона и шаблонизатор читает файлы с диска
сам, то скорее всего он блокирующий, что конечно же идет в разрез
event loop'ом. Делайте через fork. Как AnyEvent::DBI. Туда storable
hash с данными, обратно html. Конечно же вы потеряете на сериализации,
передаче, десериализации и обратном процессе, но это позволит не
блокировать ваш loop.

Можно переписать шаблонизатор и сделать его не блокирующим.

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

В идеальной ситуации, все опереции ввода вывода не блокирующие. Далее
все упирается в CPU. Предела вы достигаете, когда у вас CPU жрется на
100%. Количество процессов c loop'ом должно соответствовать количеству
CPU или быть меньше. В теории добавление процессов только замедлит
работу так как шедулер ядра начнет делить один CPU между несколькими
CPU интенсивными процессами, что позитивно не скажется на пропускной
способности.

Если речь идет о том что один  запрос требует много CPU и все
остальные ждут пока он вернет управление в loop. То тут можно только
дробить задачу и периодически возвращаться к обработке других событий.
Это только уменьшит задержки для остальных клиентов, но никак не
повысит общую производительность. Если ваш CPU может подсчитать только
10 полных заданий за 1 секунду и при этом задача не нуждается в IO, то
вы можете обрабатывать 10 запросов в секунду * кол-во CPU и не более.

Все это теория и пока мой AnyEvent проект не ушел в продакшен, но
уйдет в этом месяце и там я уд точно столкнусь с практикой и возможно
пменяю свое мнение на диаметральное.

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



-- 
Best regards, Ruslan.