silent 03.10.2010 23:45
Я рекомендую — Сверхбыстрый FastCGI для PHP с phpDaemon
ВступлениеКак многие уже знают, с версией 5.3 в официальную версию PHP пришел еще один SAPI - fpm и чтобы его завести больше не нужно патчить и компилировать его вручную. Все очень рады, массово отказываются от apache и переходят на nginx и т.п.
ОднакоОднако приложение, как и раньше, образно говоря, работает все по той же схеме:
Инициализация (парсинг php-файлов, инклюдов)Инициализация фреймворка (если и не фреймворк, то все равно что-то делается в любом скрипте перед началом работы)Подключение к серверу базы данных, авторизация и выбор базы данныхВыполнение какой-то работыГенерирование ответаЗакрытие соединения с базой данныхОсвобождение памяти, выделенной под выполнение скрипта
Да, некоторые пункты можно вычеркнуть (частично) в связи с использованием опкод-кешеров (apc, xcache, eaccelerator и т.п.), но хотелось бы большего, правда ведь?
Здрасте, я ваша тетя
Обработку запросов на самом деле можно свести только к пунктам 4 и 5 (к выполнению реальной работы). Именно это нам и предлагает FastCGI-сервер в phpDaemon, о котором на этом сайте я ничего не нашел, как ни странно.
Для затравки - небольшой бенчмарк, там с переходом на FastCGI от phpDaemon приложение без особых переделок получило ускорение в два раза.
Как это работает?
Не будем углубляться в дебри, опишу опять же образно.
При создании инстанса приложения в воркере производится вся инициализация, в приложении выполняется метод, в котором можно подключиться к базе данных и выполнить что-то для подготовки приложения. Дальше воркер просто получает запросы и передает в уже инициализированный инстанс (количество таких запросов перед пересозданием воркера можно задать в настройках).
Все очень просто, не так ли?
Всегда есть какое-то но
И это но - невозможность использования phpDaemon на шаред-хостинге (по крайней мере пока хостеры не захотят). Для установки phpDaemon нужен нормальный доступ к командной строке сервера и нужны такие дополнения как pecl-libevent, pecl-runkit (причем не официальный) и pecl-proctitle (это опционально).
Однако мы с вами сознательные разработчики и очень любим свой проект, поэтому он запущен хотя бы на VPS, поэтому нам это "но" не страшно.
Установка
Проще всего на данный момент в установке пользователям Gentoo Linux, вся установка сводится к добавлению в layman специального оверлея (как - описано на странице по ссылке внизу) и выполнению команды (на самом деле придется еще размаскировать некоторые пакеты для пользователей на стабильной ветке):
1 |
|
Установка на Debian-подобных дистрибутивах выглядит примерно так:
Ставим SAPI cli и dev-пакет, с которым идет phpize, он понадобится для сборки
1 |
|
Ставим libevent
1 |
|
Ставим pecl-libevent
1 |
|
Скорее всего будет предупреждение о том, что это бета-версия и предложение установить через канал, тогда надо будет установить через него.
Ставим pecl-proctitle (дополнение нужно для обзывания процессов говорящими названиями, поэтому оно не обязательно)
1 |
|
Ставим runkit (можно и без него, но потеряются некоторые фичи)
1 |
git clone git://github.com/zenovich/runkit.git
|
Не забываем прописывать в конфиг загрузку каждого из этих расширений (лучше разбить на несколько файлов, я приведу все вместе):
1 |
vim /etc/php5/conf.d/phpdaemon.ini
|
Забираем свежую версию phpDaemon куда-нибудь в /opt, к примеру, и создаем ссылку:
1 |
cd /opt
|
Не так страшно, как казалось сначала, правда ведь?
После этого нам надо посмотреть в папке conf файл с примером настройки phpd.conf.example. Убираем постфикс .example и после запуска демона у нас уже будет запущен FastCGI-сервер на 127.0.0.1:9000.
Поставили, а дальше-то что?
А дальше необходимо создать инстанс приложения в папке applications (можно просто поставить туда ссылку) следующего вида:
Для того, чтобы приложение обрабатывало запросы необходимо передавать в phpDaemon параметр APPNAME, в nginx это делается так:
1 |
|
Developers, developers, developers
На мой взгляд от интереса к проекту к его реальному использованию люди доходят довольно редко. Для такого проекта это, на мой взгляд, странновато.
Над проектом постоянно ведутся работы, в нем очень много функций и помимо сервера FastCGI, разработчик отзывчив и всегда идет на встречу. Пробуйте, читайте русскоязычную Wiki, спрашивайте (можно здесь), внедряйте и радуйтесь.
Можно (и даже нужно) даже форкать и пушить свои реквесты.
P.S. Нужно чем-то дополнить пост? Не хватает примеров? Пишите, все сделаем.

+ 2 -
cat!!!!
наш уважаемый коллега
он имел ввиду спрятать, скрыть часть текста со страницы и ленты RSS используя тег КАТ
Анонс очень интригует, но могли бы вы побольше раскрыть о том как работает этот PhpDaemon?
Я давно к нему приглядываюсь, но из всех статей понял только что он может работать в связке с comet сервером..
И ещё, я так понимаю что инстанс висит постоянно, а как разруливаются права с различными пользователями? Надо где-то вычищать все пользовательские данные из памяти или предусмотрен механизм автоочистки или вообще нет никаких общих данных?
Вообщем хотелось бы больше примеров и объяснения схемы работы.
Я давно к нему приглядываюсь, но из всех статей понял только что он может работать в связке с comet сервером..
И ещё, я так понимаю что инстанс висит постоянно, а как разруливаются права с различными пользователями? Надо где-то вычищать все пользовательские данные из памяти или предусмотрен механизм автоочистки или вообще нет никаких общих данных?
Вообщем хотелось бы больше примеров и объяснения схемы работы.
phpdaemon - это просто демон, который может спаунить воркеров и выполнять определенные действия с помощью приложений. Приложений в нем довольно много, FastCGI и WebSocketOverComet - одни из них.
На примере приложения FastCGI (вкратце) - приложение при запуске биндит сокет и обрабатывает запросы, приходящие снаружи, и отдает в приложение (какому приложению отдать запрос режает определенный объект), в приложении вызывается beginRequest, которое возвращает HTTPRequest, результат работы которого отдается клиенту.
Если нужно подробнее, то жду вопросов конкретнее :)
Пора перестать приглядываться и уже попробовать на деле, не пожалеете.
На примере приложения FastCGI (вкратце) - приложение при запуске биндит сокет и обрабатывает запросы, приходящие снаружи, и отдает в приложение (какому приложению отдать запрос режает определенный объект), в приложении вызывается beginRequest, которое возвращает HTTPRequest, результат работы которого отдается клиенту.
Если нужно подробнее, то жду вопросов конкретнее :)
Пора перестать приглядываться и уже попробовать на деле, не пожалеете.
И про пользователей и их права я немного не понял, если честно. Если возможно, уточните.
Дело в том, что тогда приходится сервер перегружать, чтобы увидеть изменения на своей странице, или выдумывать что-то более хитрое, как-то замена кода в процессе выполнения (как это сделано по-моему в Erlang, или как это сделано с методами в java).
Ну и еще php до версии 5.3 так и не научился очищать нормально память, как написали сами разработчики демона.
Смотрите:
php в веб работат по принципу:
1. Получили запрос.
2. Компилируем исходный текст, подгружем либы и т.п.
3. Выполняем получивший байткод.
4. Отправляем ответ.
5. Чистим память.
6. Выгружаем байткод.
Всякие кешеры убирают пункты 2 и 6, потому получается значительно быстрее. Но поскольку файл каждый раз не компилируется и не перегружается, то внесение изменений файл влечет за собой необходимость рестарта сервера, чтобы кешер перегрузил данные. Как и делали все perl и java-разработчики. Но разработчики php решили, что это излишество (ну и пусть повышает в несколько раз производительность, кому это нужно то? :) )
Но есть языки, которые поддерживают горячую замену кода (http://en.wikipedia.org/wiki/Hot_swapping#Software). Например, Erlang,java. Для Python есть подобная возможность хоть и боком
php в веб работат по принципу:
1. Получили запрос.
2. Компилируем исходный текст, подгружем либы и т.п.
3. Выполняем получивший байткод.
4. Отправляем ответ.
5. Чистим память.
6. Выгружаем байткод.
Всякие кешеры убирают пункты 2 и 6, потому получается значительно быстрее. Но поскольку файл каждый раз не компилируется и не перегружается, то внесение изменений файл влечет за собой необходимость рестарта сервера, чтобы кешер перегрузил данные. Как и делали все perl и java-разработчики. Но разработчики php решили, что это излишество (ну и пусть повышает в несколько раз производительность, кому это нужно то? :) )
Но есть языки, которые поддерживают горячую замену кода (http://en.wikipedia.org/wiki/Hot_swapping#Software). Например, Erlang,java. Для Python есть подобная возможность хоть и боком
Ну как минимум apc уже давно сам перекомпилирует файл, сразу как только он изменился. Я думаю, другие кешеры тоже неглупые, так что рестарт не нужен в этом случае.
В phpdaemon все по-другому и файлы действительно компилируются один раз - при запуске воркера. Именно поэтому там есть автоимпорт изменений с помощью runkit, так что его тоже рестартовать не надо :)
В phpdaemon все по-другому и файлы действительно компилируются один раз - при запуске воркера. Именно поэтому там есть автоимпорт изменений с помощью runkit, так что его тоже рестартовать не надо :)
По мне так еще один вариант кручения FastCGI.
Для обычных веб приложений (типа водпресс) всяко php-fpm лучше будет.
Для обычных веб приложений (типа водпресс) всяко php-fpm лучше будет.
fpm будет медленнее, особенно на вордпрессе. угадайте почему (или перечитайте статью).
Намного ли? стабильнее ли? вот в чем вопрос... :)
Вроде fpm сам через libevent работает, а с тем же eaccelerator мне кажется немного устапит.
Надо будет погонять на тестовом сервачке под нагрузкой.
Один вопросик:
Вот тут
Ничего не надо добавлять что бы запустить тот же вордпресс? Просто передать переменную через нджинкс?
Вроде fpm сам через libevent работает, а с тем же eaccelerator мне кажется немного устапит.
Надо будет погонять на тестовом сервачке под нагрузкой.
Один вопросик:
Вот тут
// тут мы обрабатываем наш запрос, все как обычно
echo 'blablabla';
echo 'blablabla';
Ничего не надо добавлять что бы запустить тот же вордпресс? Просто передать переменную через нджинкс?
Начнем снизу: для каждого приложения необходимо создавать инстанс (кратко описан в конце статьи), просто так взять и запустить WordPress не получится, с ним придется поковыряться.
Теперь остальное
С любым акселератором код приложения все равно будет загружаться и выгружаться из памяти на каждом запросе, с phpdaemon этого нет. Но это - не главная фича. Главная фича - один инстанс обрабатывает множество запросов, т.е. помимо единой компиляции исходников на запуске воркера можно выполнить много чего полезного - соединиться с базой (представляете, вместо сотни-двух коннектов к базе будет штук 20), что-то там предварительно обработать, использовать кеш не через apc/memcache/что-то еще, а хранить что-то мелкое, что нужно всегда прямо в инстансе приложения.
Посмотрите сколько всего делается при выполнении запроса в обычном WordPress'е и большинство этих задач можно выполнять один раз, перед запуском воркера.
А потом посмотрите на то, как загружаются переводы - их можно кешировать в пределах инстанса.
Я думаю, много чего можно придумать в пределах WordPress'а, я просто не очень его хорошо знаю - он меня пугает своим кодом ;)
Теперь остальное
С любым акселератором код приложения все равно будет загружаться и выгружаться из памяти на каждом запросе, с phpdaemon этого нет. Но это - не главная фича. Главная фича - один инстанс обрабатывает множество запросов, т.е. помимо единой компиляции исходников на запуске воркера можно выполнить много чего полезного - соединиться с базой (представляете, вместо сотни-двух коннектов к базе будет штук 20), что-то там предварительно обработать, использовать кеш не через apc/memcache/что-то еще, а хранить что-то мелкое, что нужно всегда прямо в инстансе приложения.
Посмотрите сколько всего делается при выполнении запроса в обычном WordPress'е и большинство этих задач можно выполнять один раз, перед запуском воркера.
А потом посмотрите на то, как загружаются переводы - их можно кешировать в пределах инстанса.
Я думаю, много чего можно придумать в пределах WordPress'а, я просто не очень его хорошо знаю - он меня пугает своим кодом ;)
Спасибо за уточнение, я так и понял изначально.
Это конечно все очень круто, но если задуматься о применении подобных вещей на начальной стадии проектирования хайлоад проекта, то на ум сразу приходят такие вещи как twisted(python), руби с его примочками и т.д.
Переводить существующие проекты на это дело просто не выгодно (дешевле докупить серверных мощностей), только если задумали координальную смену архитектуры.
Это конечно все очень круто, но если задуматься о применении подобных вещей на начальной стадии проектирования хайлоад проекта, то на ум сразу приходят такие вещи как twisted(python), руби с его примочками и т.д.
Переводить существующие проекты на это дело просто не выгодно (дешевле докупить серверных мощностей), только если задумали координальную смену архитектуры.
Ну, тут все зависит от приложения и от программистов. Относительно грамотно написанные приложения (WordPress к ним не относится, по крайней мере пока) перевести на phpdaemon не очень сложно.
Ну и в любом случае при создании нового проекта с php-программистами дешевле остаться на php :)
Ну и в любом случае при создании нового проекта с php-программистами дешевле остаться на php :)