PHP mod

Php mod Оригинал: Why is FastCGI /w Nginx so much faster than Apache /w mod_php?

Сначала я собирался написать пост о том, почему Nginx в связке с FastCGI работает быстрее, чем Apache с mod_php. Не так давно ходили слухи, что Nginx с запущенным PHP через FastCGI производительнее, чем Apache с mod_php. Многие знакомые утверждали, что это чистая правда. Некоторое время назад я провел небольшое исследование по этому вопросу и собрал интересные факты.

Сегодня я хотел бы подробно рассказать о своих поисках истины и проанализировать получившиеся результаты. Так вот, для начала замечу, что раньше мне приходилось увеличивать производительность. Если мне не изменяет память, это было необходимо и для работы с Magento.

Для тестирования я сделал простенький скрипт «привет, мир». Почему такой простой? Потому что когда вы работаете с интерпретатором PHP, не должно быть никакой разницы в производительности. Тогда почему не сделать пустую страницу? Потому что для чистоты эксперимента необходимо обеспечить двустороннюю связь. Моей целью было проверить пропускную способность веб-сервера, а не PHP. Так что я потратил минимум времени на PHP и все внимание уделил проверке передачи данных.
Базовые тесты показывают следующее:

Apache + mod_php

Total transferred: 3470000 bytes
HTML transferred: 120000 bytes
Requests per second: 2395.73 [#/sec] (mean)
Time per request: 4.174 [ms] (mean)
Time per request: 0.417 [ms] (mean, across all concurrent requests)
Transfer rate: 811.67 [Kbytes/sec] received

NginX + PHP-FPM

Total transferred: 1590000 bytes
HTML transferred: 120000 bytes
Requests per second: 5166.39 [#/sec] (mean)
Time per request: 1.936 [ms] (mean)
Time per request: 0.194 [ms] (mean, across all concurrent requests)
Transfer rate: 801.82 [Kbytes/sec] received

Apache обрабатывает 2400 запросов в секунду, по сравнению с 5200 запросами которые за то же время обрабатывает Nginx. Этот показатель вырос. Чтобы разобраться, я запустил отладочный режим для Apache с ключами -с и -f. Ключ -c показывает суммарное время на системные вызовы, ключ -f отслеживает форки. В результате мы получили вот что:

% time seconds usecs/call calls errors syscall
— — — — — — 33.65 0.042063 4 10003 getcwd
16.10 0.020127 2 10001 writev
16.00 0.019994 2 10001 shutdown
10.54 0.013179 0 51836 40118 open
9.01 0.011263 1 20008 semop
5.22 0.006522 0 54507 10002 read
2.53 0.003158 0 10024 write
1.91 0.002386 0 88260 66483 close
1.57 0.001959 245 8 clone
1.16 0.001455 0 54832 384 stat64

getcwd? Почему? Я вспомнил, что я оставил опцию AllowOverride в. Htaccess включенной. Так что я снова протестировал систему, но уже поменял значение AllowOverride на None.

Total transferred: 3470000 bytes
HTML transferred: 120000 bytes
Requests per second: 5352.41 [#/sec] (mean)
Time per request: 1.868 [ms] (mean)
Time per request: 0.187 [ms] (mean, across all concurrent requests)
Transfer rate: 1813.40 [Kbytes/sec] received

Получается, что Apache со своими 5352 запросами в секунду опережает Nginx. Но что делать, если надо передать больше данных? Я увеличил размер данных и провел повторное тестирование.

Apache

Total transferred: 1051720000 bytes
HTML transferred: 1048570000 bytes
Requests per second: 2470.24 [#/sec] (mean)
Time per request: 4.048 [ms] (mean)
Time per request: 0.405 [ms] (mean, across all concurrent requests)
Transfer rate: 253710.79 [Kbytes/sec] received

NginX

Total transferred: 1050040000 bytes
HTML transferred: 1048570000 bytes
Requests per second: 2111.08 [#/sec] (mean)
Time per request: 4.737 [ms] (mean)
Time per request: 0.474 [ms] (mean, across all concurrent requests)
Transfer rate: 216476.53 [Kbytes/sec] received

В этом случае опять можно заметить преимущество веб-сервера Apache. Смысл заключается в следующем. Apache имеет встроенный интерпретатор mod_php, что и позволяет ему работать быстрее. Поэтому, если вы используете только PHP, Apache — лучший выбор для повышения производительности. И если вы вдруг наблюдаете значительную разницу в производительности, то вы должны проверить, включена ли опция AllowOverride. Если это так, попробуйте поменять значение в httpd.conf и повторите попытку.

Если вы работаете с разным содержимым, добавляете CSS, JS, изображения, тогда Nginx обеспечит лучшую общую производительность, но он не будет работать быстрее PHP. Также, Nginx будет лучше реагировать на атаки типа отказа в обслуживании, но, как правило, на снижение риска такого рода направлен сервис CDN.
Таким образом, если вы работаете с чистым PHP, Apache остается для вас самым эффективным решением.

www.phptime.ru

Предлагаю вашему вниманию свои изыскания по вопросу производительности php (а точнее, предпочтительный вариант конкретно для Битрикса) в разных режимах запуска. Целью не было получить какие-то цифры по возможной посещаемости, а именно сравнить разные варианты при прочих равных условиях.

Небольшая вводная

GGI — самый старый способ запуска скриптов (в том числе и php). В этом случае на каждый хит запускается интерпретатор php как самостоятельное приложение и ему отдаётся скрипт для запуска. Скрипт должен вернуть заголовки, затем код html страницы. После этого интерпретатор прекращает свою работу.

Модуль Apache — в этом случае php постоянно находится в памяти веб сервера, не тратится время на запуск интерпретатора.

FastCGI — эволюция CGI интерфейса, в этом случае php запускается отдельным процессом, но после выполнения скрипта не прекращает свою работу.

Действительно ли он такой быстрый, этот FastCGI? Проверим!

Инструменты

На одной машине установлен Apache 2.2 + MySQL 5, а также демонстрационный сайт «Битрикс Бизнес». Кеширование компонентов битрикс отключил чтобы случайное пересоздание кеша не повлияло на результаты.
Здесь я умышленно не акцентирую внимание на аппаратной части и конфигурации т.к. повторюсь, задача не получить абсолютные величины, а сравнить разные режимы работы php.
Другая машина по локальной сети создаёт имитацию нагрузки на сервер. Для этого я использовал .
Он написан на Java и сам создаёт приличную нагрузку , поэтому для чистоты эксперимента мне пришлось его «отделить» от сервера.

JMeter

План тестирования состоял из 6 страниц, по 2 параллельных запроса. Постарался выбрать наиболее динамически загруженные страницы, для удобства дал им условные названия по контенту. Не следует ассоциировать скорость отдачи страниц с одноимёнными модулями.
Загружался только динамический код страниц без статики, соответственно nginx не использовал (подробности в ).

Итак, всё готово, приступаем к тестированию.

Тестирование без акселератора php

CGI
Получился следующий график суммарных результатов по всем страницам:
cgi
Синий — среднее время отдачи на каждом хите в мс
Пурпурный — статистическое среднее
Красный — отклонение от среднего
Зелёный — скорость отдачи страниц

В итоге имеем среднее время 5,5 секунды на страницу, скорость отдачи страниц — 105 в минуту.
Обратите внимание, здесь время на страницу — это время, которое реально ждёт пользователь, а не среднее по всем параллельным запросам (во втором случае мы получим 105/60 = 1,75 сек на страницу).

Отдельно по страницам получилась такая диаграмма (среднее время ответа):

Модуль Apache

php_mod

Здесь уже результат получше — 122 страницы в минуту. И соответственно, диаграмма:

FastCGI

fastcgi

Совсем неплохой результат по сравнению с традиционным CGI: 120 страниц в минуту, чуть медленнее, чем модуль.
Диаграмма:

Еще по теме: Главная страница (Is Page)

Но как изменится картина если установить акселератор php?

Результаты тестирования с установленным EAccelerator

CGI — EA
Известно, что акселератор не работает в CGI режиме т.к. ему нужен доступ к общей памяти из всех процессов. Но в phpinfo есть информация о том, что eaccelerator загружен и создаётся ощущение, что он работает. Давайте проверим.

cgi-ea

108 страниц в минуту. Это практически тот же результат что и был. Диаграмма:

Модуль Apache

309 страниц в минуту, среднее время ожидания ответа 1 секунда. Я бы сказал, это уже что-то. Ну и соответственно по страницам:

FastCGI

fcgi-ea

294 страницы в минуту, т.е. примерно на 5% медленнее, чем модуль. Но всё равно не идёт ни в какое сравнение с традиционным и неторопливым CGI режимом.

В среднем по страницам также прослеживается небольшое отставание от модуля.

А есть ли другие проблемы?

Как CGI, так и FastCGI работают независимо от веб сервера. А это значит что если происходит какая-то ошибка, веб сервер не получает заголовки от скрипта и возвращает нам в ответ » на стороне сервера». Чтобы узнать какая произошла ошибка, надо смотреть логи сервера, к которым далеко не всегда есть прямой доступ у пользователя. В случае модуля Apache ошибка может сразу отобразиться на экране (если включен вывод ошибок) и отладка скриптов осуществляется гораздо проще и быстрее.
В CGI/FastCGI режимах есть проблема с авторизацией HTTP, как следствие — проблема с интеграцией с 1С, есть и другие специфические проблемы.
При загрузке в Apache модуля php мы получаем замечательную возможность менять на лету некоторые настройки php через .htaccess, в CGI/FastCGI опять же получим ошибку 500.
Основной довод сторонников CGI/FastCGI — это безопасность. Т.к. php работает как отдельное приложение — пользователи хостинга на системном уровне отделены друг от друга, а в режиме модуля существует гипотетическая возможность ломать соседние сайты на хостинге. Отчасти это так, но на сегодняшний день существуют определённые механизмы защиты и по опыту техподдержки могу сказать, что основную проблему безопасности пользователей представляют трояны, которые воруют пароли ftp и вживляют паразитный код на сайты.

Хостеры часто используют CGI т.к. в этом случае гораздо удобнее управлять [читать: резать] ресурсами пользователей. И в итоге получаем «непонятные ошибки».

Хочу упомянуть ещё об одном важном моменте: сегодня php идёт одним файлом для CGI и FastCGI режимов, в phpinfo видим:
А значит слабо представляется возможным на пользовательском уровне выяснить, как на самом деле работает php. Учитывая скудную документацию по настройке FastCGI очень может быть, что вы будете введены в заблуждение.

Выводы или «Как же выбрать хостера?»

Если вы простой пользователь, вероятно, прокрутили весь технический груз чтобы сразу найти ответ на вопрос.

Пишу результаты.

Выбирайте CGI режим если ваш сайт посвящён восточной философии и время загрузки страниц посетителей сайта не волнует.
FastCGI даёт хорошие результаты по производительности, но ему присущи проблемы CGI режима, а это постоянные ошибки сервера «500».
В остальных случаях рекомендую использовать php как модуль Apache. Особенно если речь идёт о выделенном сервере или VPS.
Обязательно обращайте внимание на акселератор php. К сожалению, многие хостеры не уделяют этому вопросу должного внимания.
И вот ещё важный момент: не выбирайте в качестве хостера соседа по лестничной клетке, порой элементарное неумение настроить систему приносит больше проблем, чем всё остальное. Выбирайте профессионалов.
Рекомендуем перед долговременной покупкой хостинга тестировать его . Мы периодически обновляем скрипт с учётом новых проблем.

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

dev.1c-bitrix.ru

Недавно я слышал, что NginX, работающий с PHP через FastCGI был быстрее Apache с mod_php. Я также видел, что люди как отрицают, так и соглашаются с этой гипотезой. Давайте проведем небольшой тест и узнаем показатели работы этих систем.

Для тестирования я создал небольшой Hello world скрипт. Почему я не выбрал что-то посложнее? Ответ прост: в интерпритаторе PHP не должно быть особой разницы производительности. Почему же тогда я не создал абсолютно пустую страницу? Дело в том, что хотелось протестировать двунаправленную передачу данных. Целью является тестирование скорости работы веб-сервера в целом, а не только PHP.

Базовые тесты дают нам следующие результаты:.

Apache с mod_php

Total transferred: 3470000 bytes


   HTML transferred: 120000 bytes
   Requests per second: 2395.73 [#/sec] (mean)
   Time per request: 4.174 [ms] (mean)
   Time per request: 0.417 [ms] (mean, across all concurrent requests)

Transfer rate: 811.67 [Kbytes/sec] received

NginX с PHP-FPM

Total transferred: 1590000 bytes


   HTML transferred: 120000 bytes
   Requests per second: 5166.39 [#/sec] (mean)
   Time per request: 1.936 [ms] (mean)
   Time per request: 0.194 [ms] (mean, across all concurrent requests)

Transfer rate: 801.82 [Kbytes/sec] received

Apache удалось обработать 2400 запросов в секунду в отличии от Nginx. Он справился с 5200 запросами. Такого большого количества я раньше никогда не видел. Я выполнил те же запросы с -c -f для Apache, чтобы узнать причины такой разницы. -c отображает время системных запросов, -f следует ответвлениям. Какой же результат для первых 10 строк?

% time seconds usecs/call calls errors syscall


  ------ ----------- ----------- --------- --------- ----------------
   33.65 0.042063 4 10003 getcwd
   16.10 0.020127 2 10001 writev
   16.00 0.019994 2 10001 shutdown
   10.54 0.013179 0 51836 40118 open
   9.01 0.011263 1 20008 semop
   5.22 0.006522 0 54507 10002 read
   2.53 0.003158 0 10024 write
   1.91 0.002386 0 88260 66483 close
   1.57 0.001959 245 8 clone

1.16 0.001455 0 54832 384 stat64

getcwd? Но почему? После я вспомнил, что у меня активировано AllowOverwrite (.htaccess). Выполнил те же тесты после отключения этой функции.

Total transferred: 3470000 bytes


  HTML transferred: 120000 bytes
  Requests per second: 5352.41 [#/sec] (mean)
  Time per request: 1.868 [ms] (mean)
  Time per request: 0.187 [ms] (mean, across all concurrent requests)

Transfer rate: 1813.40 [Kbytes/sec] received

С 5352 обработанными запросами Apache опередил NginX. Но что же произойдет тогдпн, когда объем передаваемых данных увеличится? Я создал около 100k контента и попробовал снова.

Apache

Total transferred: 1051720000 bytes


  HTML transferred: 1048570000 bytes
  Requests per second: 2470.24 [#/sec] (mean)
  Time per request: 4.048 [ms] (mean)
  Time per request: 0.405 [ms] (mean, across all concurrent requests)

Transfer rate: 253710.79 [Kbytes/sec] received

NginX

Total transferred: 1050040000 bytes


  HTML transferred: 1048570000 bytes
  Requests per second: 2111.08 [#/sec] (mean)
  Time per request: 4.737 [ms] (mean)
  Time per request: 0.474 [ms] (mean, across all concurrent requests)

Transfer rate: 216476.53 [Kbytes/sec] received

В этот раз разница была заметнее. Ощущаются некие изменения. PHP встроен в mod_php Apache, что должно ускорять его. Если на Вашем сервере работает только PHP, то это должно быть лучшим решением в плане производительности.

Если Вы работаете с разными языками вроде CSS, JS и изображениямм, тогда Вам больше подойдет NginX. Его производительность будет выше, но PHP быстрее не станет. Он также будет надежнее в плане защиты от DDoS, но CDN по-прежнему является лучшим решением.

Ниже представлены графики для сравнения производительности:

Php mod

habr.com

Поставим PHP 5.1.2. Где его достать? Здрасте, естественно на PHP.net. Выбираем самое близкое к себе зеркало и качаем себе ZIP. Пока качает сделаем соответствующий каталог под всё это дело по адресу /webservices/php/5/ — это делается специально, что-бы (на всякий случай) мы в любой момент могли поставить другую версию PHP и между ними переключиться.

Итак, в каталог /webservices/php/5/ мы разархивируем все файлы. Ничего сложного. Все более мение нормальные люди, знающие английский язык читают install.txt, и следуя инструкциям для соответствующих версий операционной системы и HTTP сервера. Нам актуален Apache 2.0.x on Microsoft Windows. Там есть пометка, что возможно, свеженький Apache 2 с MPM не будет нормально работать с PHP 5. У меня работает, но если у вас будут проблемы, можете отрубить всю эту красоту при помощи директивы Win32DisableAcceptEx.

Согласно рекомендациям, мы добавим путь до нашей инсталляции PHP в системный PATH. Для Windows XP идём в Control Panel и запускаем System, в закладке Advanced выбираем Environment Variables. Там,в разделе System variables выбираем в режиме редакции системную переменную Path, добавляем туда /webservices/php/5/ (с нужным символом диска и нужными слешами). Осталась мелочь — перезапустить систему.

Теперь нам нужно выбрать конфигурацию для PHP. С собой PHP приносит 2 версии конфигурации php.ini-dist и php.ini-recommended. Создатели рекомендуют использовать php.ini-recommended — он сконфигурирован для безопастности и скорости работы. Очень советую пересмотреть его и комментарии в нём. Я же предпочитаю php.ini-dist, с мелкими изменениями. Оба конфигурационных файла очень хорошо документированы, и настойчиво рекомендую вам со всем этим делом ознакомиться. Во первый я его ложу в директорию /webservices/apache/Apache2/conf — я разделяю конфигурации связанные с модулем и остальными случаями.

Мелкие изменения в php.ini (в php.ini я использую "/" слеши — оно прекрасно понимает):
error_reporting с E_ALL & ~E_NOTICE на E_ALL — разрабатываете проекты что бы в таком режиме небыло никаких сообщений об ошибок.

include_path делаю так, что бы оно могло брать PEAR — include_path = “.;/webservices/php/5/PEAR/” (незабудьте исправить слеши и символ диска).

upload_tmp_dir надо указать директорию для временный файлов, которые закачивают пользователи. Там они будут лежать, пока вы их не обработаете с move_uploaded_file или unlink. Для всего этого сделаем каталог /tmp и укажем его для ключа upload_tmp_dir.

extension_dir указываю путь до каталога с модулями PHP “/webservices/php/5/ext/”.

В разделе [mail function] указываем SMTP сервер провайдера для ключа SMTP и адрес своей электронной почты для ключа sendmail_from.

В разделе [Session] для session.save_path укажем туже директорию /tmp — нам этого хватит для разработки.

В известном нам httpd.conf добавим (вполне можем сделать это в кoнце файла) сточки:

LoadModule php5_module "/webservices/php/5/php5apache2.dll" — Подгружаем модуль

AddType application/x-httpd-php .php — улазываем что .php файлы обрабатывает PHP процессор
и

PHPIniDir "/webservices/apache/Apache2/conf" — указываем где лежит php.ini

Сделаем apache.exe -t и видим Syntax OK. Пробуем запустить наш сервер. В какой-либо из наших каталогов, доступных через HTTP протокол, ложим файл phpinfo.php с таким содержанием (скорее всего мы положим его в наш www.example.com или default виртуальный сервер/хост):

и видим всю информацию о PHP. Это чистый, только со встроенными модулями, PHP 5.

Но, для разработки нам нужно на много больше — подключим несколько модулей: php_mbstring, php_curl, php_exif, php_gd2, php_mysql, php_pgsql, php_sqlite, php_mysqli. Вот только, проверьте, есть ли такие DLL в директории /webservices/php/5/ext/, а если нет, скачайте Collection of PECL modules и разархивируйте их в директорию /webservices/php/5/ext/.
С версией PHP 5.1 сразу идёт и модуль PDO, и тем, кто любит или хочет им пользоваться или ознакомиться, может себе его легко включить, достаточно подключить: php_pdo и соответствующие к нему библиотеки (к примеру, php_pdo_mysql для поддержки MySQL). Я лично, делаю большую ставку на PDO в будущем. Рестартуем наш Apache и вновь смотрим на phpinfo.php — видим что нами выбранные модули уже загрузились.

Вот и всё — у нас стоит PHP как модуль Apache 2. Более подробно обо всём вы можете прочесть на сайте PHP.net, а также советую запомнить вот это прекрасное место.

www.internet-technologies.ru

Решил навести в голове порядок о том, как работают вместе веб-сервер и PHP.

CGI

Содержание

0.1 CGI
0.2 FastCGI
0.3 PHP в режиме CGI
0.4 PHP в режиме FastCGI
0.5 PHP-FPM
0.6 mod_php

1 PHP в режиме CGI
2 PHP в режиме FastCGI
3 PHP-FPM
4 Модуль Апач (mod_php)

Common Gateway Interface, «общий интерфейс шлюза» — это стандарт, который описывает, как веб-сервер должен запускать прикладные программы (скрипты), как должен передавать им параметры HTTP-запроса, как программы должны передавать результаты своей работы веб-серверу. Прикладную программу взаимодействующую с веб-сервером по протоколу CGI принято называть шлюзом, хотя более распространено название CGI-скрипт или CGI-программа.

В качестве CGI-программ могут использоваться программы/скрипты написанные на любых языках программирования, как на компилируемых, так и на скриптовых, и даже на shell.

CGI-скрипты были популярны до того, как для веб-разработки стали преимущественно использовать PHP. Хотя сам PHP интерпретатор позволяет работать в режиме CGI (см. ниже).

Основной момент: «CGI» это не язык программирования и не отдельная программа! Это просто протокол (стандарт, спецификация, соглашение, набор правил).

Примеры CGI-скриптов, схема работы CGI.

FastCGI

Дальнейшее развитие технологии CGI, является более производительным и безопасным, снимает множество ограничений CGI-программ.

FastCGI программа работает следующим образом: программа единожды загружается в память в качестве демона (независимо от HTTP-сервера), а затем входит в цикл обработки запросов от HTTP-сервера. Один и тот же процесс обрабатывает несколько различных запросов один за другим, что отличается от работы в CGI-режиме, когда на каждый запрос создается отдельный процесс, «умирающий» после окончания обработки.

Написание FastCGI программ-демонов сложнее чем CGI, нужны дополнительные библиотеки, зависящие от языка.

Опять же, сама аббревиатура FastCGI это не язык программирования и не отдельная программа, это как и в случае CGI — просто спецификация.

PHP в режиме CGI

PHP в режиме CGI это самый старый способ выполнения php-скриптов веб-сервером. Режим доступен по умолчанию, однако может быть отключён при компиляции.

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

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

PHP в режиме FastCGI

Помимо CGI режима, PHP из коробки умеет работать и в FastCGI режиме (с версии 5.3 даже в двух FastCGI режимах). Режим включается флагом при компиляции интерпретатора, флаг зависит от версии PHP.

Для работы с Apache нужен модуль mod_fcgid или mod_fastcgi, либо связка из mod_proxy_fcgi + PHP-FPM.

Nginx умеет работать с FastCGI приложениями из коробки, но именно для PHP дополнительно нужен PHP-FPM (см. ниже).

Следует помнить, что при работе PHP в режиме FastCGI в памяти висит сам php интерпретатор, а не какой-то конкретный php-скрипт.

PHP-FPM

FastCGI Process Manager, «Менеджер процессов FastCGI». Это альтернативная реализация FastCGI режима в PHP с несколькими дополнительными возможностями, которые обычно используются для высоконагруженных сайтов.

Изначально PHP-FPM представлял из себя набор патчей от Андрея Нигматулина, которые устраняли ряд проблем, мешающих полноценно использовать PHP в режиме FastCGI (список улучшений). С версии PHP 5.3 набор патчей включён в ядро, а дополнительные возможности PHP-FPM включаются флагом при компиляции.

PHP-FPM используется в основном в связке с Nginx, без установки Apache.

mod_php

Это модуль для Apache, позволяющий ему выполнять php скрипты. Является наверно самым популярным и простым способом подружить Apache и PHP. Модуль не использует ни CGI, ни FastCGI. Есть свои минусы — скрипты работают под пользователем веб-сервера, невозможно использовать больше одной версии PHP.

PHP в режиме CGI

Common Gateway Interface (CGI), «общий интерфейс шлюза» — это стандарт, который описывает, как веб-сервер должен запускать прикладные программы (скрипты), как должен передавать им параметры HTTP-запроса, как скрипты должны передавать результаты своей работы веб-серверу. Прикладную программу взаимодействующую с веб-сервером по протоколу CGI принято называть шлюзом, хотя более распространено название CGI-скрипт или CGI-программа.

В качестве CGI-программ могут использоваться программы/скрипты написанные на любых языках программирования, даже на shell.

PHP в режиме CGI это самый старый способ выполнения php-скриптов веб-сервером. Режим доступен по умолчанию, однако может быть отключён при компиляции.

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

PHP в режиме FastCGI

FastCGI программа работает следующим образом:

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

Написание FastCGI программ сложнее чем CGI, нужны дополнительные библиотеки, зависящие от языка.

Для работы с Apache нужен модуль mod_fcgid или mod_fastcgi, либо связка из mod_proxy_fcgi + PHP-FPM.

Nginx умеет работать с FastCGI приложениями из коробки, но именно для PHP дополнительно нужен PHP-FPM (см. ниже).

PHP-FPM

FastCGI Process Manager, «Менеджер процессов FastCGI». Это альтернативная реализация FastCGI режима в PHP с несколькими дополнительными возможностями, которые обычно используются для высоконагруженных сайтов.

Изначально PHP-FPM представлял из себя набор патчей от Андрея Нигматулина, которые устраняли ряд проблем, мешающих полноценно использовать PHP в режиме FastCGI (список улучшений). С версии PHP 5.3 набор патчей включён в ядро, а дополнительные возможности PHP-FPM включаются флагом при компиляции.

PHP-FPM используется в основном в связке с Nginx, без установки Apache.

Модуль Апач (mod_php)

Это модуль для Apache, позволяющий ему выполнять php скрипты. Является наверно самым популярным и простым способом подружить Apache и PHP. Модуль не использует ни CGI, ни FastCGI. Есть свои минусы — скрипты работают под пользователем веб-сервера, невозможно использовать больше одной версии PHP.

Источники:

Основной текст: http://xandeadx.ru/blog/php/866

fkn.ktu10.com

Вот говорят, php-fpm рулит…

Тестировал я намедни оба варианта на своем любимом кластере отдачи 🙂

Кластер держит в среднем 50 обращений в секунду к пхп-скрипту.

Пхп скрипт выполняет коннект к удаленной базе, делает SELECT, читает файл, делает операции с регекспами (preg_match), выплевывает результат и делает INSERT.

Апач:

# httpd -l
Compiled in modules:
core.c
mod_access.c
mod_auth.c
mod_auth_anon.c
mod_log_config.c
mod_logio.c
mod_env.c
mod_expires.c
mod_headers.c
mod_setenvif.c
prefork.c
http_core.c
mod_mime.c
mod_status.c
mod_asis.c
mod_info.c
mod_dir.c
mod_actions.c
mod_alias.c
mod_so.c
==============================

Основной конфиг:
Timeout 20
KeepAlive Off
StartServers 50
MinSpareServers 5
MaxSpareServers 10
ServerLimit 2500
MaxClients 1024
MaxRequestsPerChild 10000
LoadModule php4_module libexec/apache2/libphp4.so

==============================
Результат (1 из трех зеркал):
21.3 requests/sec — 152.4 kB/second — 7.2 kB/request
3 requests currently being processed, 7 idle workers

PHP-FPM:

<value name=»listen_address»>127.0.0.1:9000</value>
<value name=»backlog»>-1</value>
<value name=»style»>apache-like</value>
<value name=»max_children»>512</value>
<value name=»StartServers»>100</value>
<value name=»MinSpareServers»>5</value>
<value name=»MaxSpareServers»>35</value>

Последний обосрался по полной. Мало того, что количество процессов никогда не снижал ниже установленных max_children (512), отъедая хороший кусок памяти, так еще и дропал каждое второе-третье соединение (Nginx выдавал 502 Bad Gateway)

А апач живет себе, держит в памяти штук 10 детишек и обрабатывает все на ура.

ru-highload.livejournal.com

Нет комментариев

PHP mod

CGI

FastCGI

PHP в режиме CGI

PHP в режиме FastCGI

PHP-FPM

mod_php

PHP в режиме CGI

PHP в режиме FastCGI

PHP-FPM

Модуль Апач (mod_php)

Добавить комментарий Отменить ответ