Общеизвестный факт, что PHP это такое средство разработки домашних страниц, что совершенно исключает его применение для крупных проектов. Но с годами домашняя страничка выросла, а время на переписывание всего с нуля взять неоткуда. Пришлось изменить название языка и обвешиваться инфраструктурой, чтобы получить какой то компромисс в производительности.

Как все работает

Для тех, кто далек от программирования поясню. Браузер посетителя запрашивает у сервера страницу. Тот (пускай, Apache) находит файл на диске и обнаруживает, что он оканчивается на PHP. За этим следует вызов модуля PHP. А может даже и отдельной программы, если тот установлен как CGI. В обмен переданному файлу с программным кодом сервер получает HTML-код, который летит к пользователю.

Представьте, что посетителей несколько. А лучше даже 100 человек одновременно. И для каждого посетителя выполняются одни и те же действия. С одним и тем же результатом.

Догадливый читатель мог подумать, что если поставить перед сервером Apache что-то, что будет сохранять HTML-код и не дергать лишний раз PHP, то это похоже на решение. Например, прокси в лице Squid или хорошо настроенный Nginx (здесь можно обойтись и без Apache). Но в общем случае это подходит только, если ваш посетитель — читатель, а не писатель.

Мы приходим к тому, что никуда не деться от постоянного вызова PHP скрипта. Еще хуже, что это не просто скрипт, а CMS. В одном запросе участвует пара десятков PHP-скриптов различных библиотек, классов. А еще работал тут когда-то программист, который вместо встроенной в язык функций написал свою в 100 строк и одному сложному запросу предпочел два простых с обработкой данных на PHP. А еще комментарии составляют 30% от объема файла.

Пока вы это читали, интерпретатор PHP тысячу раз занимался тем, что перечитывал содержимое PHP-файла и удивлялся написанному там.

Но вообще, эта проблема решена давным давно. Лет так 10 назад. И я зря писал обо всем этом. Встречаем PHP-ускорители!

Обзор PHP-ускорителей

Все они устроены одинаково. Из цепочки выполнения запроса исключается та часть, где с диска берется PHP-файл и интерпретируется в машинный код (байткод — прим. dark_barker).

Технически это модуль для PHP. Так что важно, чтобы он поддерживал используемую вами версию PHP.

XCache (http://xcache.lighttpd.net/)
Разработан одним из тех людей, которые работают над сервером Lighttpd. Относительно новый. Вместе со стабильной первой веткой идет работа над второй версией.

eAccelerator (http://eaccelerator.net/)
Когда-то форк от бесплатного и заброшенного Turck MMCache. До начала 2007 умел кодировать исходники. А с недавнего релиза вместе с поддержкой PHP 5.3 разучился хранить сессии и работать с пользовательским кешем (об этом позже).

ionCube PHP Encoder (http://www.ioncube.com/)
Одно из первых решений с акцентом на кодирование исходников. В какое-то время остановился в развитии, а позже осталась только коммерческая версия. Остается на плаву, но дальнейшая судьба не ясна.

Windows Cache Extension (http://www.iis.net/expand/WinCacheForPHP)
Возможно, что единственное решение для IIS-сервера. Поддержка PHP 5.3, копирайт Майкрософта.

Alternative PHP Cache (APC) (http://pecl.php.net/package/APC)
Находится в официальном хранилище расширений и легко устанавливается. Оперативно обновляется. Будет включен в PHP 6, так что надеюсь скоро эта статья потеряет свою актуальность.

Zend Optimizer+ (http://www.zend.com/en/products/server-ce/index)
Распространяется в составе Zend Server.

NuSphere PHPExpress (http://www.nusphere.com/products/phpexpress.htm)
Еще один ускоритель (спасибо morkovnik). Но главная фишка в том, что он работает с файлами закодированными их же платным Nu-Coder-ом для дальнейшего коммерческого распространения. Только вот сами их представители не могут назвать ни одного Shared-хостинга, где бы использовался PHPExpress. Кроме основной функции ничего не умеет. Поддержка PHP 5.3 обещана в начале 2010 (сообщение на их форуме). Распространяется в скомпилированном состоянии в виде расширений для 4.3, 4.4, 5.0, 5.1., 5.2.

Замеры скорости

Прибавка в скорости очевидна, что не требуется никаких замеров ))) Но следует обратить внимание на то, что кеш со временем устаревает и чтобы не вышло так, что после изменения кода выполняется все еще закешированный — модуль проверяет дату модификации файла. Это влияет на быстродействие, поэтому на рабочем проекте директиву проверки можно отключить.

Также обычно настраивается место хранения кода (память или диск) и его объем.

Делаем окончательный выбор

Я мельком упомянул работу с пользовательским кэшем. Это общее временное key/value-хранилище в памяти. Оно естественно быстрее, чем Memcache, так как исключает задержки сетевого протокола. Но ограничено одной физической машиной, на которой исполняется скрипт.

Поддержка этой функциональности есть во всех актуальных модулях: в APC, XCache и Zend Server (в лице Data Cache), а в eAccelerator она по-умолчанию выключена.

Выбор из этих четырех — дело личных предпочтений.