Вы наверняка уже наслышаны о протоколе FastCGI, который служит каналом связи с приложением.

Популярное применение — связь между Веб-сервером и Веб-приложением, его реализации есть во множестве языков. Протокол поддерживается многими Веб-серверами, среди них nginx и lighttpd. Однако,

в популярном языке PHP, реализация протокола до не столь давних пор была представлена лишь патчем PHP-FPM, который де-факто не выигрывает у Apache-prefork mod_php, поскольку он, вопреки идеологии

FastCGI, запускает скрипт каждый раз с нуля, не говоря уже об асинхронности I/O. Идеология же FastCGI подразумевает единоразовую инициализацию приложения (подгрузку нужных библиотек, соединение с

базой данных, и т.д.), и выполнение запросов один за другим или вообще параллельно (событийно переключаясь между контекстами запросов).

Модуль FastCGI в phpDaemon — правильная реализация FastCGI, которая позволяет добиться немыслимой производительности и снижения нагрузки на систему. Теперь нам не нужно тысячи раз в секунду копировать мегабайты памяти, не надо каждый раз соединяться с базой данных и проходить у нее

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

оп-кода (eAccelerator) даст прирост лишь в случае использования компилирующих шаблонизаторов.

Давайте для начала разберём архитектуру — как же всё это работает, а затем я расскажу о предоставляемых вкусностях, и мы уделим значительное время вашим вопросам.

phpDaemon — это вполне самостоятельный демон, способный обрабатывать соединения по нескольким TCP- и UNIX-сокетам. Он  использует libevent. Для начала работы вам необходимо создать файл с приложением в папке applications и выполнить phpdaemon start.

Мастер-процесс создаст нужное количество рабочих процессов, которые начнут принимают новые соединения в пул, читать из них данные и  делегировать выполнение запросов нужным приложениям руководствуясь указаниями AppResolver’а. При этом вы можете выполнять какие-то процедуры с запросом даже до окончания обработки тела запроса.

Строго говоря, операции принятия соединения, приема данных, обработки запроса, и передачи ответа — асинхронны, т.е. мы можем принять два или больше соединений и поочередно их читать и обрабатывать в рамках одного процесса PHP (количество в рамках лимита max-concurrent-requests-per-worker). Разумеется, выполнение более одного конкурентного запроса в рабочем процесса потребует от программиста хранить все запросо-зависимые данные в экземпляре класса Request, и обеспечить отсутствие блокировок процесса. Это позволяет выполнять десятки тысяч запросов в секунду. Архитектура в чем-то похожа на nginx. Архитектура позволяет легко создавать свои событийные сетевые сервисы, в дистрибутиве поставляются реализации FlashPolicy, HTTP, FastCGI, LockServer, TelnetHoneyPot, MemcacheClient, MongoClient…

Не станем вдаваться в подробности, но это действительно легко, и работать придётся лишь с оберткой, не думая о низком уровне.

Слайд №1: Спектр возможностей очень широк (всё опциально):

• Умный MPM.

• Модульная структура и API. /*К примеру, можно написать свой менеджер процессов, учитывающий

фазу луны.*/

• Возможность смены пользователя и корня рабочих процессов.

• Поддержка Request-Body-File, X-Sendfile, multipart, attachment (callback), UCS-2.

• Прием APPNAME.

• Авто-сборка мусора (GC).

• Лимиты для рабочего процесса.

• Статус рабочих процессов.

• Асинхронность выполнения запросов.

• Асинхронная работа с сетью (libevent).

• Встроенный модуль асинхронного CGI-сервера (libevent).

Слайд №2: Где это можно применить особенно эффективно?

• Любые системы использующие PHP.

• Сетевые Веб-приложения (IM-гейты, чаты).

• Торрент-трекеры.

Хотите немного серверной магии? Представьте себе несложную задачу: реализовать простецкую загрузку видео-файлов по HTTP, конвертацию их в FLV, и разумеется сохранение. Вы наверняка напишите простейший скрипт с использованием move_uploaded_file() и exec(), который будет висеть пока клиент отправляет запрос, кто-то пойдет дальше и будет записывать в БД идентификаторы файлов ожидающих конвертации, используя для конвертации отдельную пачку процессов, это позволит ограничить кол-во

одновременно конвертируемых файлов. А теперь я хочу немного вас удивить, я готов реализовать всю эту схему используя лишь 1 процесс PHP (ну,

строго говоря — 2, учитывая мастер-процесс, но он не участвует в обработке). При этом не будет никакой потери в производительности, и мне даже не понадобится база данных (хотя, в нее стоит сбрасывать состояние, чтобы защититься от сбоев питания). Как? Очень просто. Достаточно создать приложение с использованием phpDaemon: в run() методе класса Request проверять счетчик работающих процессов конвертацию (обычную переменную), и если лимит не превышен — открывать pipe’а с ffmpeg’ом и класть его в свойство запроса, ну и вызвать $this->sleep(), при повторном вызове проверять состояние pipe и в случае его завершения – завершать запрос (я имею в виду именно запрос в очереди рабочего процесса,

броузер получит страничку и отключится задолго до этого). Как это работает? Очень просто. Как я уже говорил, обработка запросов асинхронна, и рабочий процесс будет принимать сразу несколько upload’ов и раскидывать кусочки по временным файлам, а когда запрос полностью принят — будет мгновенно открывать pipe c ffmpeg и возвращаться к пресловутой обработке.

Кстати, по такому же принципу работает встроенный CGI-сервер, служащий для подключения сторонних приложений.Подробнее о демонге вы можете посмотреть на сайте проекта.

Василий Зорин, kak.serpom.po.yaitsam@gmail.com.