Записки сисадмина

Битва PHP: Apache vs PHP-FPM

Я не раз сцеплялся в админских обсуждениях на тему нецелесообразности PHP-FastCGI. Споров много, реальных данных мало. Замечу сразу, да, я лицо заинтересованное. Но подтасовкой не занимался и в ходе теста, три раза готов был признать свою ошибку

Немного теории. Я вообще не знаю, почему все FastCGI реализации PHP носят префикс «Fast». Ведь Fast-CGI это целый интерфейс работы скрипта, под него нужно оптимизировать скрипты, чтобы получить его достоинства. Но мало того что этого никто не делает, для этого в PHP вообще не существует никаких интерфейсов. Ну на эту тему можно почитать статью: почему FastCGI не ускоряет PHP

Я решил сравнить апач с широкоизвестным fpm менеджером. В плане производительности.

Что тестировалось?

Тестировались различные варианты использования mod_php(5) + apache(1,2) против использования наиболее популярного FastCGI-спаунера PHP – PHP-FPM.

Железо сервера: AMD Sempron LE-1150 1600MHz, M/B Abit A-N68SV, 1,5 Gb DDR RAM

Система: CentOS 5 Final x86_64. ядро 2.6.18-53.el5

Прочее: Распределенная файловая система IBM GPFS. Это не имеет отношения к тесту, просто так получилось )

Какие версии софта использовались?

Я обращаю внимание: Apache использовался лишь в качестве бекенда для выполнения скриптов. Если его нагрузить статикой, все будет намного хуже. Но ведь FastCGI-сервер мы не нагружаем статикой?

1. Apache 2.0.63, mpm worker, dso mod_php v 5.2.6, нет лимита чайлдов
2. Apache 2.0.63, mpm worker, dso mod_php v 5.2.6, ServerLimit-> 1, MaxThreads -> 75
3. Apache 2.0.63, mpm prefork, dso mod_php v 5.2.6, ServerLimit-> 5
4. Apache 1.3.41, mpm prefork, статический mod_php v 5.2.6, MaxClients ->7
5. Nginx 0.6.31, php-fpm v 5.2.6 via unix socket, php-fpm MaxServers -> 5

Поскольку «соревнование» по параметру потребляемой памяти было в разных весовых категориях (PHP-FPM умеет держать в памяти только фиксированное число процессов, в то время как apache динамически регулирует их количество), то к тесту № 4 все шансы уровнялись.

Как было выбрано минимальное кол-во серверов для нагрузки?

Методом «научного тыка» Исходя из фиксированного кол-ва конкурентных запросов, для тестов 3-5 было выявлено минимальное количество воркеров, после которого результаты либо резко ухудшались, либо сервер отклонял некоторые попытки соединения.

Софт для тестирования

На стороне клиента: siege-2.66

На стороне сервера: самописный перловый скрипт, который снимает нужные параметры по нагрузке по типу vmstat. Исходник: monitor.pl Примечание: мне было лень обрабатывать аргументы командной строки, по этому для мониторинга других процессов нужно изменять 1ю строку.

Команда запуска siege для всех случаев была следующая: siege -i -c 60 -d 0 -t 2m -f siege.in

• -c 60 : 60 конкурентных запросов. Число было подобрано примерно в потолок загрузки сервера
• -t 2m : длительность 2 минуты
• -f siege.in : список URL, 5000шт
• -i : выбирать URL случайно из списка

Скрипт тестирования

Был выбран рабочий php-скрипт с локального проекта. По скольку именно его функциональность меня беспокоила, то на нем я остановился. Исходник показывать не буду. Расскажу алгоритм:

1. коннект к удаленной базе
2. SELECT по параметрам GET
3. куча условий
4. Выдирание файла с файловой системы соотв. параметрам GET.
5. 5 хитрых preg_replace
6. Выплевывание html

Процесс тестирования

1. На клиенте запускается siege
2. Почти синхронно на сервере запускается monitor.pl, который выдает данные по загрузке системы и процессов каждые 5 секунд.
3. Ожидается окончание осады
4. Данные по siege и monitor.pl складываются в файл для дальнейшего анализа. Слишком «хорошие» начальные и конечные показатели monitor.pl отбрасываются.

1. Apache 2.0.63, mpm worker, dso mod_php v 5.2.6, нет лимита чайлдов

Apache compilation: apache.config.txt
Apache config: httpd.conf.txt
php compilation: php.config.txt
php config: compile-default/no php.ini.

2. Apache 2.0.63, mpm worker, dso mod_php v 5.2.6, ServerLimit-> 1, MaxThreads -> 75

Apache compilation: apache.config
Apache config: httpd.conf
php compilation: php.config
php config: compile-default/no php.ini.

3. Apache 2.0.63, mpm prefork, dso mod_php v 5.2.6, ServerLimit-> 5

Apache compilation: apache.config
Apache config: httpd.conf
php compilation: php.config
php config: compile-default/no php.ini.

4. Apache 1.3.41, mpm prefork, статический mod_php v 5.2.6, MaxClients ->7

Apache compilation: apache.config
Apache config: httpd.conf
php compilation: php.config
php config: compile-default/no php.ini.

5. Nginx 0.6.31, php-fpm v 5.2.6 via unix socket, php-fpm MaxServers -> 5

Nginx compilation: nginx.config
Nginx config: nginx.conf
php-fcgi compilation: php.config
php-fcgi config: php-fpm.conf
php config: compile-default/no php.ini.

РЕЗУЛЬТАТЫ.

Результаты я наглядно оформил в файл MS Excel: FastCGI.zip. При желании можно скачать и узнать все подробности.

Здесь я приведу финальную таблицу:

Поля:

• Elapsed Time – Среднее время теста
• Response Time – Среднее время ответа
• Transaction Rate – Среднее кол-во транзакций в сек
• Throughoutput – Пропускная способность
• Concurrency – Среднее количество одновременных запросов
• MEM RSS (KB) – Средний объем занимаемой памяти всеми процессами httpd (в случае 1-4) или php-cgi в случае 5
• CPU User, CPU System, CPU Idle – Средние показатели утилизации процессора на машине на время теста

Цвета:

• Красным – отмечены худшие показатели
• Зеленым – лучшие

ВЫВОДЫ

Ну чесно говоря, когда я запускал первые три теста последовательно, апач2, апач2, fpm – у меня сложилось действительно представление о моей неправоте. Тогда я решил уровнять шансы и тесты 2,3,4 прошли уже с лимитированием процессов апача.

Внезапный отрыв вперед Apache 1.3 меня очень конечно обрадовал

Итак, пусть тест далеко не идеальный, но можно сделать кое какие выводы.

Вся технология PHP-FCGI базируется на чем угодно, только не на том, что из себя представляет fast cgi для таких например языков как Perl & C со своими интерфейсами скриптинга.

Если уравнять условия apache и php-fpm, php-fpm единственное в чем выигрывает, то это в памяти, ито за счет двух дополнительных процессах апача. Остальные выигрыши довольно сомнительны.

Если с апача убрать обработку статики и всего лишнего (например с помощью nginx), он довольно шустро обрабатывает скрипты.

С другой стороны, в PHP-FPM довольно красиво реализована схема chroot’а и запуска из под отдельных юзверей, что повышает безопасность. Но он проигрывает в IPC, т.к. пока не умеет изменять количество воркеров пропорционально нагрузке. Если поставить слишком много воркеров, будет overhead по CPU и памяти (за что грешат на апач), если поставить слишком мало – будут отказы в обслуживании. Ну впрочем, кому резонно вручную следить за процессами FPM, те этим занимаются.

11.07.2008 Автор admin | Очумелые ручки, Тестовая площадка | 10 comments