2011/1/13 Ivan Petrov <[email protected]>: > >> Поделите обработку на несколько очень мелких по времени работы фаз и >> после обработки каждой фазы возвращайте управление в 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 > [email protected] | http://moscow.pm.org > > -- Best regards, Ruslan. -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
