Elettracompany.com

Компьютерный справочник
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Php как fastcgi

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.

Комментарии

недавно начали ддосить! взял сервак нанял сисадмина настроил все гуд!
Nginx + PHP-FPM

отличная статья. Коротко, по делу и дает ответы на все вопросы. спасибо!

Спасибо большое! Познавательно

Замечательная статья. Заменила две недели поисков информации в интернете.

Спасибо большое!
Подскажите, а PHP-FPM содержит в себе php? Если я ставлю PHP-FPM мне не нужно ставить php, получается это как бы надстройка над интерпретатором ?

Смотря что, как и где ставите. Читайте документацию.

а в случае PHP-FPM сам скрипт компилируется 1 раз и потом отдаётся всем уже из памяти?

если не стоит какой-нибудь opcache, который это умеет, то нет

стоит, стоит, конечно стоит
он же в составе идёт с 5.5 вроде

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

Спасибо. Коротко, емко, грамотно!

Большое спасибо за статью! Лаконично и понятно.

Спасибо, понятно и по полочкам)))

Спасибо за статью, многое, что не мог нигде найти стало понятно!

Менеджер процессов FastCGI (FPM)

Содержание

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

Эти возможности включают в себя:

    продвинутое управление процессами с корректной (graceful) процедурой остановки и запуска;

    возможность запуска воркеров с разными uid/gid/chroot/окружением, а также запуска на различных портах с использованием разных php.ini (замещение safe_mode);

    логирование стандартных потоков вывода (stdout) и ошибок (stderr);

    аварийный перезапуск в случае внезапного разрушения opcode-кеша;

    поддержка ускоренной загрузки (accelerated upload);

    «slowlog» — логирование необычно медленно выполняющихся скриптов (не только их имена, но также и их трассировки. Это достигается с помощью ptrace и других подобных утилит для чтения данных исполнения удаленных процессов);

    fastcgi_finish_request() — специальная функция для завершения запроса и сброса всех буферов данных, причем процесс может продолжать выполнение каких-либо длительных действий (конвертирование видео, обработка статистики и т.п.);

    Динамическое/статическое порождение дочерних процессов;

    Базовая информация о статусе SAPI (аналогично Apache mod_status);

    Конфигурационный файл, основанный на php.ini.

    User Contributed Notes 8 notes

    Init script setup
    ===

    You will probably want to create an init script for your new php-fpm. Fortunately, PHP 5.3.3 provides one for you, which you should copy to your init directory and change permissions:

    /sapi/fpm/init.d.php-fpm.in /etc/init.d/php-fpm
    $ chmod 755 /etc/init.d/php-fpm

    It requires a certain amount of setup. First of all, make sure your php-fpm.conf file is set up to create a PID file when php-fpm starts. E.g.:
    —-
    pid = /var/run/php-fpm.pid
    —-
    (also make sure your php-fpm user has permission to create this file).

    Now open up your new init script (/etc/init.d/php-fpm) and set the variables at the top to their relevant values. E.g.:

    prefix=
    exec_prefix=
    php_fpm_BIN=/sbin/php-fpm
    php_fpm_CONF=/etc/php-fpm.conf
    php_fpm_PID=/var/run/php-fpm.pid

    Your init script is now ready. You should now be able to start, stop and reload php-fpm:

    Читать еще:  Asp phpsessid carbonate btc

    $ /etc/init.d/php-fpm start
    $ /etc/init.d/php-fpm stop
    $ /etc/init.d/php-fpm reload

    The one remaining thing you may wish to do is to add your new php-fpm init script to system start-up. E.g. in CentOS:

    $ /sbin/chkconfig php-fpm on

    Disclaimer: Although I did just do this on my own server about 20 mins ago, everything I’ve written here is off the top of my head, so it may not be 100% correct. Also, allow for differences in system setup. Some understanding of what you are doing is assumed.

    I’m very unhappy with the way php-fpm handles requests.
    There isn’t even some SCRIPT_FILENAME in the RFC for CGI, an that’s the only standard I found to handle the requests.

    Actually what you are doing with PATH_TRANSLATED is supposed to translate to the path, which is broken by media wikis, as they use the PATH_INFO to find the ressource, not some script.

    In the original CGI context, the PATH_INFO is passed to the CGI binary to specify some ressource argument. So actually

    in command context.

    Conclusion: We should rewrite php-fpm to obey the rfc3875 CGI standard.
    Having SCRIPT_NAME pointing to /something.php, must translate to

    CWD is the working directory where php-fpm is started (or configured to change to).

    In case of chroot CWD = «».

    In any case the SCRIPT_NAME php script can be found with ./SCRIPT_NAME, from the CWD. So the undocumented not standardized SCRIPT_FILENAME should vanish! It breaks the CGI standard.

    «mod_php vs CGI vs FastCGI» или «Как выбирать хостера»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Хочу упомянуть ещё об одном важном моменте: сегодня php идёт одним файлом для CGI и FastCGI режимов, в phpinfo видим:

    А значит слабо представляется возможным на пользовательском уровне выяснить, как на самом деле работает php. Учитывая скудную документацию по настройке FastCGI очень может быть, что вы будете введены в заблуждение.

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

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

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

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

    >Хорошо если есть возможность.
    У нас вот как раз другой случай. Я именно и хотел отметить, что мы «не имели возможность» (сейчас конечно имеем), а «были вынуждены» самим заморачиваться. И это был хоть и проблемный, но полезный опыт.
    А началось все с того, что один из проектов, которым я занимаюсь, переехал на выделенный сервер, арендованный у одного хостера. (я позже скажу кто это) Сервер взяли с администрированием, т.е. они должны были все поддерживать и следить за сервером. После некоторых переговоров с ТП хостера, и ихних заверений, что сделаем все как надо (я им скидывал ваши рекомендации), мы оплатили и перенесли сайт. И начались проблемы. Сайт лежал по два часа в день. Перечислять что и как все решалось, сколько времени я убил на разговоры почти со всеми из их ТП и т.д. — мне пол дня понадобится.
    Я, тем временем болея за проект, сам вникал во всю вашу документацию по настройке (я то как раз мат. часть хорошо знаю — т.е. теорию и все технологии. и мне все понятно, но вот где ручками что сделать надо, увы — нет практики) и вместе с ТП хостера пытался выяснить в чем проблема.
    В итоге они нас «развели» на гиг памяти, хотя надо признаться он реально был нужен. После этого вроде стало все стабильно работать, но прошла неделя стабильной работы и опять начались проблемы такие же. Хотя посещаемость не выросла, нагрузка тоже. Начались опять дебаты, в процессе которых они начали опять говорить про еще два гига памяти. Причем аренда гига памяти у них стоит 350 рублей в месяц, при стоимости самого гига в 800 р Я сразу понял, что дело тут не чисто. я человек прямой, и когда я понимаю, что мне пудрят мозги, я просто посылаю открытым текстом в жопу (а то еще дальше, но рядом), что я и сделал.
    Естественно они это перенести не смогли и даже пообещали в одностороннем порядке расторгнуть договор (чего они не сделали, конечно,ибо были бы юридически не правы).

    После такого поворота событий я был вынужден искать помощи, кстати в первую очередь обратился здесь на форуме. Откликнулся Евгений Педан, за что ему отдельное спасибо. Он нам там «подкрутил некоторые гайки», и кстати он и обнаружил, что там даже не стояло (. ) php-акселератора. Вообщем хостер реально плевать хотел на те ваши рекомендации, которые я им скидывал, кстати, они потом прокомментировали это так: битрикс кто? пишет цмс? ну вот и пусть пишет — они нам не показатель, а мы хостинг компания — нам лучше знать.

    Нафига нам было обещать тогда рекомендации выполнить до заключения договора. Непонятно..

    Евгений нам помог, но решить полностью проблему не смог, т.к. сервер на FreeBSD, а Евгений опытен в Linux. Вообще пришлось открывать свою записную книжку старую, и искать контакты бывших однокашников и прочих, кто мне мог помочь. После чего, вышел на очень профессиональных людей, один из которых за два дня привел все в порядок. Сервер стал работать стабильно.

    На момент проблем нагрузка была около 7000. Сейчас бывает и по 20000. И сервер справляется без проблем. Но мы уже глядя в будущее собрали свой сервер более мощный. За весь период общения с профессионалами, я многое узнал. С теми с кем я общаюсь, работают в серьезных организациях, например в РЖД, где обеспечивают работу систем безопасности — серьезные ребята вообщем (многие бородатые ).

    Так вот они поведали, что режим mod_php при грамотной сборке должен быть производительней в среднем на 20% чем FastCGI. Причем если нужно отделить пользователей, то даже использование виртуальных ОС, на каждую из которых естественно тратятся ресурсы, дает фору режиму FastCGI. Но использование виртулов требует больше памяти.

    Надо отметить у Вас даже получились неплохие результаты в пользу FastCGI.

    Nginx. Использование PHP в режиме FastCGI с помощью php-fpm

    У меня стоял Apache 2.2 и mod_php, так как Apache жрет не мало ресурсов, я решил постепенно переводить проекты на сервере на связку Nginx + PHP-FastCGI, а в качестве спаунера php-fpm.

    Вкратце, что такое FastCGI и почему он лучше чем mod_php?

    FastCGI это высокопроизводительный и масштабируемый интерфейс для взаимодействия web-сервера и приложений, дальнейшее развитие технологии CGI. Ознакомиться с более подробной информацией о FastCGI вы можете на официальном сайте или в Википедии.

    Основное преимущество FastCGI в изолировании динамического языка от web-сервера. Например, запуск FastCGI процесса под пользователем, отличным от пользователя web-сервера, а также процесс может находиться в chroot’е, отличном от chroot’а web-сервера. Помимо всего прочего, эта технология позволяет запускать web-сервера и CGI процессы (теже php скрипты) на различных хостах, что улучшает масштабируемость и также способствует безопасности без существенной потери в производительности.

    Читать еще:  Main php cmd share details

    Ну а зачем нам php-fpm, если PHP и так поддерживает работу в режиме FastCGI?

    php-fpm — это патч для PHP, для использования PHP как FastCGI процесса в высоконагруженных системах. Устраняет ряд проблем мешающих использовать PHP в режиме FastCGI. Андрей Нигматулин представил набор патчей php-fpm к PHP 4/5, устраняющих ряд проблем, которые мешают использовать PHP в режиме FastCGI на высоконагруженных системах.

    Возможности php-fpm:

    * Управление процессами. Возможность «плавно» останавливать и перезапускать php воркеры без потери запросов. Возможность плавно обновлять конфигурацию и binary без потери запросов;
    * Ограничение ip адресов, с которых могут приходить запросы от web сервера;
    * Динамическое количество процессов, в зависимости от нагрузки (TODO);
    * Запуск воркеров с разными uid/gid/chroot/environment и разными php.ini опциями;
    * Логирование stdout & stderr рабочих процессов;
    * Аварийный перезапуск всех процессов при случайном разрушении shared memory opcode cache, если используется акселератор;
    * Принудительное завершение подвисших процессов, если set_time_limit() не срабатывает (TODO);

    Кстати, в видео я тоже поучаствовал, на 5-ой минуте и 20-ой секунде я там прохожу перед камерой в костюме и красной футболке. 😀

    Установка Nginx

    На самом деле Nginx у меня был уже установлен, но для полноты статьи я расскажу как и его установить. В зависимости от необходимого функционала, либо от стабильности версии, вам надо выбрать подходящую версию Nginx. Стабильная находится в каталоге «/usr/ports/www/nginx/», а более новая в «/usr/ports/www/nginx-devel/», у меня стоит именно вторая.

    Всё, Nginx установлен, добавьте его в автозагрузку:

    Установка php-fpm

    Процесс заключается в пропатчивании и переустановки PHP интерпретатора с поддержкой FastCGI и php-fpm.

    Установка из сорцов

    Заходим на оф. сайт проекта php-fpm, в раздел загрузок http://php-fpm.org/download и выбираем подходящую для вашего PHP интерпретатора версию патча. У меня это PHP 5.2.10, поэтому я буду ставить именно его.

    Теперь, скопируем скрипт инициализации php-fpm в каталог «/usr/local/etc/rc.d» и назначим ему права на запуск:

    Установка из портов

    Тут все намного проще. 🙂

    Завершение установки

    После установки, проверьте версию php:

    Если «built» сегодняшний, то всё оки, если нет — отпишите в комментарии, помогу разобраться.
    Я ставил и из сорцов и из портов, так что все проверено на себе! 🙂

    Добавим в автозагрузку:

    Настройка Nginx

    Теперь настраиваем Nginx, отредактируйте конфиг «/usr/local/etc/nginx/nginx.conf» или свой «vhost»:

    Чуть более подробно о конфигурации nginx тут и тут.

    Настройка php-fpm

    Я покажу части конфига, которые только отличаются от «php-fpm.conf.default», весь конфиг можно взять тут.

    «82.146.63.195» — это ип моего сервера, на котором крутится nginx. Ему то мы и разрешим доступ.

    Запуск

    Теперь осталось только запустить nginx и php-fpm:

    Если не запустилось, то смотрите «/var/log/php-fpm.log». Если нету файла лога вообще, то создайте его и права на запись выставите.
    Вот и все, в следующей статье расскажу о spawn-fcgi (раньше входил в lighttpd).

    Комментарии

    Блииин, че нету в пакетах nginx и php шоле?

    Режимы работы 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;

    Меньшее потребление оперативной памяти.

    • Отсутствует поддержка конфигурационного файла .htaccess. Это требует самостоятельной настройки аналогичных правил на стороне веб-сервера Nginx.

    О выборе режима PHP

    Выбор режима PHP зависит от требований ваших сайтов и доступных ресурсов сервера. В большинстве случаев мы рекомендуем использовать клиентам режим FastCGI, так как он подходит для корректной работы большинства CMS и требует меньше действий со стороны пользователя.

    Откройте для себя возможности виртуального выделенного сервера на SSD.

    Ссылка на основную публикацию
    Adblock
    detector