Как работает php cgi
Коротко о CGI, FastCGI, PHP-FPM и mod_php
Все указанные ниже механизмы являются SAPI, которые позволяют серверу взаимодействовать со сценариями, написанными на PHP.
PHP в режиме CGI
PHP в режиме CGI это самый старый способ выполнения php-скриптов веб-сервером. Режим доступен по умолчанию, однако может быть отключён при компиляции. Для Apache нужен модуль mod_cgi (поставляется вместе с Apache). Nginx из коробки поддержки не имеет, хотя существуют дополнительные инструменты. В данный момент режим используется редко в силу малой производительности.
Common Gateway Interface — это стандарт, который описывает, как веб-сервер должен запускать прикладные программы (скрипты), как должен передавать им параметры HTTP-запроса, как программы должны передавать результаты своей работы веб-серверу. Прикладную программу взаимодействующую с веб-сервером по протоколу CGI принято называть шлюзом, хотя более распространено название CGI-скрипт или CGI-программа.
В качестве CGI-программ могут использоваться программы/скрипты написанные на любых языках программирования, как на компилируемых, так и на скриптовых, и даже на shell. CGI-скрипты были популярны до того, как для веб-разработки стали преимущественно использовать PHP.
PHP в режиме FastCGI
Помимо CGI режима, PHP из коробки умеет работать и в FastCGI режиме (с версии 5.3 даже в двух FastCGI режимах). Режим включается флагом при компиляции интерпретатора, флаг зависит от версии PHP.
Следует помнить, что при работе PHP в режиме FastCGI в памяти висит сам php интерпретатор, а не какой-то конкретный php-скрипт.
FastCGI — это дальнейшее развитие технологии CGI, является более производительным и безопасным, снимает множество ограничений CGI-программ.
FastCGI программа работает следующим образом: программа единожды загружается в память в качестве демона (независимо от HTTP-сервера), а затем входит в цикл обработки запросов от HTTP-сервера. Один и тот же процесс обрабатывает несколько различных запросов один за другим, что отличается от работы в CGI-режиме, когда на каждый запрос создается отдельный процесс, «умирающий» после окончания обработки.
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, FastCGI, PHP-FPM и mod_php
Решил навести в голове порядок о том, как работают вместе веб-сервер и PHP.
Common Gateway Interface, «общий интерфейс шлюза» — это стандарт, который описывает, как веб-сервер должен запускать прикладные программы (скрипты), как должен передавать им параметры HTTP-запроса, как программы должны передавать результаты своей работы веб-серверу. Прикладную программу взаимодействующую с веб-сервером по протоколу CGI принято называть шлюзом, хотя более распространено название CGI-скрипт или CGI-программа.
В качестве CGI-программ могут использоваться программы/скрипты написанные на любых языках программирования, как на компилируемых, так и на скриптовых, в том числе на shell.
CGI-скрипты были популярны до того, как для веб-разработки стали преимущественно использовать PHP. Хотя сам PHP интерпретатор позволяет работать в режиме 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.
Всё, что вы хотели знать о CLI, CGI, MOD, но стеснялись спросить
… Я знаю кун-фу, каратэ, таэквондо и еще много страшных слов!
(с) анекдот
Меня начинающие админы последнее время стали часто спрашивать «А чем отличаются пакеты php-cgi, php-cli и mod_php? И почему, например, для Python есть mod_python, но нет python-cgi?»
Сначала было смешно, но потом стало ясно, что сей вопрос хоть раз да возникал у каждого, кто занимается администрированием LAMP(ссылка) и подобных серверов.
Статья написана по мотивам моей беседы с felvis, поэтому заранее извиняюсь за некоторую вольность изложения.
Пару слов о процессах
Ещё пример, вместо команды env можно выполнить
cat /proc/self/environ
Увидите то же самое, только в менее удобочитаемом виде 🙂
Всё, теперь то что нам нужно для понимания отличий CGI и CLI мы знаем. Идём далее.
Буквы, буквы
поймёте, что имеется ввиду.
Кстати, именно из-за вышеописанного один и тот же скрипт будет работать по-разному из консоли и через браузер. Разработчик, будь внимателен при отладке!
Немного про пакеты
Теперь за Python. Почему есть mod_python, но нет python-cgi и python-cli?
Тут всё просто, проведём аналогию:
Нужно отдельно пояснить, что CGI — это Common Gateway Interface для веб-серверов (не только Апача). То есть CGI — это лишь технология, с помощью которой можно выполнять что угодно, любые бинари, которые формируют веб-страницу (хоть программы на Си писаные — пофиг). В Апаче эту технологию реализует mod_cgi — через этот модуль Апач дёргает скрипт, в котором прописан shebang #!/usr/bin/python или #!/usr/bin/php и тд — и скрипт выполняется.
Основной недостаток mod_cgi — скорость выполнения скриптов, потому-то и пишут отдельные модули для Апача, которые интепретитруют PHP, Python, shell-скрипты — так быстрее.
Конечно есть mod_fcgi, который сильно быстрее mod_cgi — но описание mod_fcgi не входит в рамки этой статьи.
_________
Текст подготовлен в ХабраРедакторе
В тексте использована картинка Binary от Brian «Visual Paradox» Kissinger.
Выбор режима работы web-сервера на личном опыте
Эта статья будет полезна тем людям, у которых уже есть свой сайт, или которые планируют его открыть. Особенно интересна статья будет амбициозно настроенным вебмастерам, которые чувствуют, что звездный час их проекта не за горами и хотят подготовиться к наплыву посетителей страницы.
Даже те, кто пока только мечтают о тысячах пользователей на своём сайте, наверняка задавались вопросом: “А сколько же пользователей мой сайт выдержит, если они зайдут одновременно?” Сразу вспоминается известное выражение “Хабраэффект” – явление отказа сайта, который оказался не готов к многочисленным переходам на него после появления в интернете ссылки.
Предположим, что сайт уже есть (или скоро будет): где же его разместить? Это должен быть классический хостинг или vps-сервер? Если vps, то какой и как его лучше настроить? А может быть вообще нет никакой разницы и проще выбрать то, что подешевле? В этой статье мы рассмотрим несколько вариантов и на практике убедимся, какой из них подойдёт лучше для нашего сайта.
Будем экспериментировать: ставить разные режимы работы сервера и замерять производительность. Нагрузку на сайт будем имитировать с помощью сервиса Loaddy.com. Там можно задать количество пользователей, нарастающий тип нагрузки и по графику будет видно, как сервер реагирует на них. Считается, что один пользователь генерирует примерно один запрос к сайту в течение 10 секунд. В качестве испытуемого сайта возьмем демонстрационный интернет-магазин на cms moguta. Он будет заполнен тестовыми «товарами», которые выводятся на главную страницу по нескольким критериям (то есть при формировании страницы идет работа с базой данных и т.п.). Так или иначе, это позволит сравнивать режимы между собой.
В качестве тестовой площадки создадим впс-сервер на ос Ubuntu. Конфигурация его будет [1 ядро, 1Gb RAM]. Будем считать, что именно такие серверы начального уровня создают в большинстве случаев для новых проектов. Тестовая версия интернет-магазина будет доступна по ip адресу http://130.193.44.219/
Еще пригодится классический хостинг, на который мы также зальем тот же самый интернет магазин, чтобы провести испытания. Вы можете пройти наш путь сами и провести такие же тесты на своем проекте!
Так как в большинстве случаев вместе с vps предлагается панель управления, основные изменения настроек будем производить в ней. На vps сервере нам доступно 3 режима его работы:
Классический недорогой хостинг
Результат доступен по ссылке.
Ошибки появляются, когда количество посетителей превышает 50 чел. Хостинг перестаёт отдавать контент, при этом, если зайти в панель управления хостингом, то мы можем увидеть примерно следующее:
Ваш сайт подвергался ограничениям в течение последних 24 часов. Ресурсы процессора ограничивались для Вашего сайта. Вы достигали пределов по входным процессам (количеству одновременно запущенных PHP и CGI скриптов, заданий по расписанию и консольных сессий) 126 раз.
Что ж, понятно, хостинг есть хостинг, тем более недорогой. Можно, конечно, найти такой тариф, который будет предоставлять больше возможностей, но это всё нужно учитывать, каким-то образом узнавать точные данные ограничений, причем у каждого хостинг-провайдера.
VPS: Apache
Следующий на очереди – наш тестовый впс с режимом апач, который кстати предлагается по умолчанию, при установке панели управления ISP.
Результат доступен по ссылке.
Проблемы начинаются, когда число пользователей переваливает за 90. Если мы зайдем на наш сервер по ssh и посмотрим в этот момент на список процессов по команде top, отсортированный с помощью Shift+M (по количеству потребляемой памяти), то увидим примерно такую картину:
Мы видим, что процесс apache2 разросся на много дочерних и они съели всю оперативку нашего vps сервера.
Здесь нужно сделать небольшую ремарку. Дело в том, что для сервера апач теоретически существует режим, который позволяет вместо этого большого числа дочерних процессов для каждого соединения создать несколько так называемых мультитредовых, каждый из которых обслуживал бы по нескольку соединений. Называется этот режим worker, в отличие от дефолтного prefork. Но установить его непросто, в панелях типа ISP это сделать невозможно, а если озадачиться и попытаться это осуществить через ssh, то выяснится, что для этого мало выключить prefork и включить worker, еще нужна тредобезопасная версия php. А если используются модули типа Zend или IonCube, то они тоже должны быть тредобезопасными. Да и вообще, официальный сайт PHP не рекомендует устанавливать этот режим.
VPS: CGI
Давайте посмотрим, что будет при использовании режима CGI. Для этого нужно в панели управления ISP разрешить использовать PHP в режиме CGI, это делается в разделе «Учетные записи – пользователи – настройки для пользователя».
Результат доступен по ссылке.
Безрадостная картина получилась. Сервер отказывается выдавать контент уже при 55+ посетителях, оперативная память вся съедена процессами “php”. Далее идёт попытка восстановления работоспособности, но всё равно всё оканчивается практически 100% отказами.
VPS: Nginx + PHP-FPM
Настало время режима, в котором сервер Apache не используется вовсе, вместо него работает Nginx, а php обрабатывается модулем php-fpm. Если вы используете панель управления ISP, то необходимо разрешить этот режим для пользователя. Это также делается в разделе «Учетные записи – пользователи – настройки для пользователя». Также этот режим должен быть доступен в разделе «Настройки – Возможности – Веб-сервер(www)».
Результат доступен по ссылке.
То, что нужно! 100% доступности, при этом скорость загрузки и время ответа сервера находятся на приемлемых уровнях, хоть и возрастают с ростом нагрузки. Тем не менее сервер справляется!
Посмотрим на таблицу процессов в момент максимальной нагрузки на сервер:
Мы видим, что у нас есть еще запас по доступной оперативной памяти. А дочерние процессы php-fpm7.0 не разрастаются в больших количествах, а ограничены 5-ю экземплярами, каждый из которых обслуживает несколько потоков.
Что ж, похоже «режим-победитель» определен. Давайте выясним, сколько же одновременных посетителей сможет обслужить наш сервер в таком режиме. Но перед этим сделаем небольшой «тюнинг». Во-первых, так как apache не используется при такой работе сервера, его можно вовсе отключить. Это сделаем в панели управления ISP в разделе «Система – Службы». Во-вторых, изменим немного принцип запуска процессов php-fpm. По умолчанию он динамический. Это значит, что дочерние процессы будут висеть в памяти даже когда они не нужны. При этом память не освобождается и со временем эти процессы могут разрастись больше чем нам бы хотелось. Поэтому предлагается установить режим “ondemand” – по требованию. И задать количество дочерних процессов и время таймаута для них.
Для этого нужно будет зайти на сервер по ssh и прописать эти настройки в конфигурационный файл php. Это удобно сделать в файле для пользователя, для которого был создан домен в ISP.
Обычно он находится в /etc/php/7.0/fpm/pool.d
Видим там по умолчанию такие настройки:
Чтобы заработал режим ondemand, нужно заменить это на:
И перезапустить php-fpm командой
После этого процессы php-fpm7.0 будут создаваться по требованию (при наличии нагрузки), максимальное их количество будет =5, а после 10 секунд простоя процесс будет убиваться, освобождая оперативную память.
На всякий случай, запустим наш тест еще раз, чтобы убедиться, что вся эта самодеятельность не повлияла в худшую сторону на производительность сайта:
Результат доступен по ссылке.
Теперь давайте запустим Loaddy с большим количеством посетителей, чтобы понять, сколько соединений способен выдержать наш сервер:
Результат доступен по ссылке.
Радует то, что все запросы были обработаны, пусть и с большой задержкой, при большом их количестве в секунду. Время ответа сервера приближается к 10 секундам при количестве обращений 190+ Но давайте вспомним график режима apache, где 4 секунды ответа сервера мы получили уже при 80+ пользователях, тогда как в режиме php-fpm аналогичные лаги наблюдаются при 130 запросах, которые мы специально выделили курсором на графике выше.
А ведь это тот же самый VPS.
Таблица процессов top в конце испытания (при 200 пользователях):
Заметим, что после окончания тестирования, память, используемая pfp-fpm освободилась:
А значит наш сервер готов к новым нагрузкам.
Заключение
В завершении еще один небольшой момент: Если вы настроили на сервере всё что хотели и решили отключить панель управления ISP, или у вас кончилась на неё лицензия, учтите, что процесс “core” от неё так и останется висеть у вас на сервере. По прошествии месяцев он может разрастись, так что лучше его “убить” и удалить из автозапуска и crona.
Режимы работы PHP: mod_php, FastCGI и PHP-FPM на VPS
Веб-серверы могут обрабатывать php-скрипты в разных режимах. Если выбрать подходящий вариант взаимодействия PHP и веб-сервера на сайте, например, PHP как CGI или Apache-модуль, это положительно отразится на его производительности.
Выбрать режим работы PHP можно на VPS с панелью управления ISPmanager и Plesk. На виртуальном хостинге REG.RU по умолчанию используется режим FastCGI.
Подробнее о том, какие режимы PHP поддерживаются на хостинге REG.RU, читайте в статье.
В этой статье мы рассмотрим основные режимы работы PHP.
PHP как модуль Apache (mod_php)
Модуль для веб-сервера Apache, который позволяет ему обрабатывать все запросы PHP, не используя сторонние модули.
Можно вводить переменные PHP в .htaccess.
отдельные пользователи на сервере с mod_php не могут вносить изменения, если у них нет прав доступа на все процессы, с которыми он работает. Иными словами, права веб-сервера должны выдаваться всем пользователям на сервере;
Низкий уровень безопасности, так как нельзя определить пользователя, который запустил конкретный процесс (все процессы выполняются анонимно под пользователем apache);
Ошибки в скриптах могут парализовать работу всего сервера;
Веб-серверы с mod_php медленно обрабатывают статические данные.
PHP в режиме CGI и FastCGI
PHP CGI — один из первых сценариев обработки php-скриптов сервером с помощью модуля mod_cgi. Сейчас он используется редко и считается устаревшим.
В этом режиме каждый php-запрос выполняется отдельным процессом. Из-за этого производительность сайта снижается, и на обработку скриптов требуется больше времени.
При создании сценария FastCGI учли медленную скорость обработки скриптов в CGI, поэтому в этом режиме используется циклическая обработка нескольких запросов одним процессом. FastCGI — это экономия оперативной памяти за счет сокращения количества запущенных процессов.
Пользователь обладает правами на выполнение всех скриптов на своем www-домене;
Безопасность (каждый запрос выполняется под отдельным пользователем, запуск небезопасного php-скрипта не повлияет на файлы других пользователей, которые находятся на одном с ним сервере);
Каждый пользователь на сервере может выбрать персональную версию PHP;
Отсутствие сбоев сервера при наличии ошибок в скриптах;
Обработка правил конфигурационного файла .htaccess, который поддерживается популярными CMS (WordPress, Joomla, 1C-Битрикс и пр.).
Чуть меньшая производительность по сравнению с модулем Apache;
Медленная обработка статических данных без связки с веб-сервером Nginx.
PHP в режиме FPM
FPM (FastCGI Process Manager) — альтернативная реализация PHP FastCGI. PHP FPM — это единственный модуль, который подходит для чистого веб-сервера Nginx.
Как работает PHP FPM:
Быстрая обработка статических данных;
Отсутствует необходимость в веб-сервере Apache;
Меньшее потребление оперативной памяти.
О выборе режима PHP
Выбор режима PHP зависит от требований ваших сайтов и доступных ресурсов сервера. В большинстве случаев мы рекомендуем использовать клиентам режим FastCGI, так как он подходит для корректной работы большинства CMS и требует меньше действий со стороны пользователя.
Закажите сервер с чистой CentOS или панелью управления ISPmanager всего за пару минут.