Php cgi что это

Php cgi что это

Интерпретатор PHP может работать в нескольких режимах. В этой статье рассматриваются следующие режимы работы:

Каждый из указанных режимов имеет как преимущества, так и недостатки. Те и другие качества в представляем ниже.

Содержание

PHP как модуль Apache (mod_php)

Этот режим предполагает подключение модуля mod_php в настройках веб-сервера Apache. В этом случае каждый процесс веб-сервера будет включать в себя этот модуль. Выбор этого режима особенно подходит для небольших сайтов с малой посещаемостью.

Преимущества:

  • Доступны настройки кэширования, за счет чего можно увеличить производительность.
  • Быстрое исполнение скриптов.

Недостатки:

  • Конфигурирование можно выполнять только через основной файл php.ini и некоторые параметры можно объявить через файл htaccess.
  • По умолчанию скрипты запускаются с правами пользователя apache. Однако это можно изменить путем использования mod_ruid, который позволяет запускать скрипты от разных пользователей.
  • Подгрузка модуля происходит во все процессы apache даже при отсутствии запросов на тип скрипта, обрабатываемый этим модулем. За счет этого создается бесполезная нагрузка на сервер.
  • Скрипт, имеющий ошибки, может привести к сбою работы веб-сервера.
  • Нет простого способа узнать, каким пользователем было запущено стороннее приложение.
  • Некоторые модули имеют проблемы в совместимости с многопоточным запуском веб-сервера (MPM Worker).

PHP в режиме CGI

В этом режиме запускается интерпретатор php-cgi для всех скриптов, для которых установлен CGI в качестве обработчика. Если большая часть сайта состоит из статического содержимого, то CGI будет хорошим выбором, т.к. будет обеспечено экономичное использование оперативной памяти за счет того, что интерпретатор будет вызываться в случае необходимости. Но и в то же время такой метод замедляет исполнение, т.к. при каждом запросе понадобится загрузка интерпретатора в память.

Преимущества:

  • Обработчик CGI может быть запущен с правами любого пользователя системы (с помощью suexec).
  • Конфигурацию PHP можно сделать индивидуальной для каждого пользователя.
  • CGI использует оперативную память только если это действительно необходимо.
  • Благодаря тому, что PHP интерпретатор работает как независимый процесс, вероятность сбоя работы Apache из-за ошибок в скриптах практически нулевая.
  • Каждый клиент может выбрать индивидуальную версию PHP.

Недостатки:

  • Не высокая производительность.
  • Разработка PHP-авторизации с командой Header имеет ограничения по причине того, что скрипт будет получать не все необходимые серверные переменные.

SuPHP

SuPHP является частным случаем CGI, в котором каждый php скрипт может выполняться с привилегиями разных пользователей.

Преимущества:

  • Можно отследить, от имени какого пользователя запускался скрипт.
  • Пользователь не сможет запустить скрипты, если он не является их владельцем.
  • Для всех файлов, которые будут загружены на сервер через сайт, будет установлен владельцем тот пользователь, от имени которого эти файлы загружались.

Недостатки:

  • Сравнительно с CGI более высокая нагрузка на CPU.
  • Недоступны функции кэширования, например, XCache, APC и др.

PHP в режиме FastCGI (mod_fastcgi)

По своим свойствам FastCGI является золотой серединой между mod_php и CGI режимами. В нём исключены недостатки CGI и присутствуют его достоинства. При включенном FastCGI, в ОЗУ сервера располагается постоянно запущенный процесс-обработчик. Это избавляет от необходимости при каждом запросе запускать новый процесс, как в случае использования CGI. По быстродействию FastCGI аналогичен mod_php.

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

Преимущества:

  • Можно улучшить производительность используя кэширование.
  • Скрипты запускаются от имени их владельца.
  • Риск зависания минимизирован за счет существования переменной, определяющей количество запросов, которые можно обслужить до плановой перезагрузки интерпретатора.
Читайте также:  Diablo 3 reaper of souls ps4

Недостатки:

  • Постоянно запущенный процесс интерпретатора создает нагрузку на оперативную память, хотя её объем меньше, чем при использовании PHP как модуля Apache. Это достигается за счет отсутствия необходимости обращения к интерпретатору PHP при выдаче статического содержимого.

LSPHP

LiteSpeed PHP (LSPHP) — реализован в виде модуля mod_lsapi на веб-сервере Apache и является наиболее производительным вариантом запуска PHP на серверах под управлением сPanel.

  • Увеличение скорости обработки PHP-скриптов, что ускоряет работу всего сайта.
  • Отсутствие 500-ой ошибки при наличии php_flag и подобных директив в .htaccess. Актуально при переезде с хостинга, который по умолчанию работал с mod_php.
  • Уменьшится потребление ресурсов в вашем виртуальном контейнере.
  • Улучшится эффективность работы Opcode Cache

На данный момент недостатков не было обнаружено.

Более подробно о работе LSPHP можно прочитать в нашем блоге в статье «Ускорьте работу своего сайта, перейдя на LSPHP».

Для того чтобы перейти на LSPHP, можно воспользоваться инструкцией из нашей вики.

Каким образом узнать текущий режим PHP?

Способ 1. С помощью функции phpinfo()

  • Создаем на хостинге php-файл c произвольным именем (например, info.php), после чего открываем его для редактирования и копируем в него следующие строки:
  • Сохраняем внесенные изменения, после чего открываем файл в браузере.
  • Если все данные были указаны верно, то в браузере будет выведена страница с развернутой информацией об установленном PHP. В перечне выведенных параметров будет присутствовать параметр Server API, в значении которого и отображается текущий режим PHP.
  • На изображении ниже показано значение параметра Server API в случае использования режима FastCGI.

Способ 2. С помощью функции функции php_sapi_name()

  • По аналогии первого способа, создаем на хостинге файл, например, info.php, затем открываем для редактирования и затем копируем следующий код:
  • После сохранения изменений открываем этот файл в браузере. В итоге должна быть отображена страница в теле которой будет выведено название используемого режима PHP. На изображении ниже представлен пример вывода при использовании режима FastCGI.

Уже знаете, какое доменное имя хотите получить для вашего веб-сайта? У нас вы можете купить домен дешево. Нужен хостинг? HOSTiQ предлагает интересные планы виртуального хостинга, а также вы сможете заказать VPS-сервер или арендовать сервер в Европе или США.

Та не, не сломаешь, в принципе. Но и DLE не будет работать нормально.

На всякий случай просто сохрани текущий конфиг, до переключения.

Просто ISP бывает глючит, когда слишком сильно модифицируешь дефолтный конфиг. А в случае с DLE его нужно модифицировать очень сильно, либо подключать инклюдом (самый верный вариант).

А если не будешь руками лазить в конфиг, и уверен, что DLE работает с дефолтным конфигом Apache — то можно и туда-обратно тыкать, ничего не сломаешь.

Это в ISP 4 с этим сложней было, там панель вообще не понимает изменения в конфигах которые вручную вносили, никакие. И сносит их к херам если начинаешь через панель трогать домены.

Что касается CGI — не совсем так, CGI точно так же через апач работает.

Годный пост. На сервере держу пока старую сборку с апачем, а вот на локалке поставил без него. Пока еще не юзал толком. Как я понял .htaceess в этой связке не работает? ЧПУ как здесь делать или все там так же работает?

Читайте также:  Total commander установка плагинов

Точно, .htaccess не пашет, ибо этот костыль умеет только апач. ЧПУ, соответственно, тоже не пашет. В этом обычно и заключается загвоздка при переключении на эту связку.
Если какая-то сложная CMS, то нужно рисовать и отлаживать конфиг под неё в Nginx.
Если обычный wordpress, то там решается довольно просто. Добавляется в конфиг такая строчка:
try_files $uri $uri/ /index.php?$args;
В блок location / <. Вот так:

Для некоторых других CMS тоже подходит этот вариант. А для того же DLE, например, надо рисовать большую портянку правил.

«Чтобы иметь преимущества php 7 его нужно обновить общесистемный. Тогда и высокопроизводительный сервис PHP-fpm станет работать на этой же версии. Но чего делать пока не рекомендуется, да и нету его еще в стабильных репозиториях большинства OS.»

Спасибо за эту статью и видео! Видео кстати также будет полезно тем, кто интересуется темой «как надо работать в терминале» )

Вопросики:
1. Если хочется php7, то на чистую ОС (как я понял сейчас мейнстрим CentOS для обычных сайтиков) сначала ставим из репозитариев php 5.5 (актуально на 06.2017) и потом еще ставим из не официальных репозитариев php7 ?
2. Или все-же на продакшн 5-ый ставят? )
3. Если Ставим Nginx то получается что apache можно вовсе не ставить…

P.S. Php7 сам по себе должен быть быстрее 5-го, т.к. в нем обновлен движок Zend и выброшено много устаревшего

Ну на самом деле тут в этой статье инфа немного уже устарела, ибо писалась на форуме более чем полгода назад. По крайней мере применительно к использованию php 7 в режиме php-fpm, особенно на сервере под управлением панельки ISPmanager 5. В нем можно в любом режиме удобно юзать любую версию PHP. И 7, и даже 7.1. Это я как раз и показывал на видео. И в другой статье http://vpsadm.ru/php-7-ispmanager-5-kak-ustanovit/

Что касается работы без панели — то сложности могут быть только при запуске в режиме апач-модуля.

В том же centos такую возможность не знаю как вкорячить. Технически это разумеется возможно, просто я пока не знаю как)

Далее по версиям OS. Это зависит исключительно от удобства администрирования, от привычки работы с ними. Для большинства задач и сайтов мне видится Centos удобней. В Debian 8 легко можно поставить обе версии параллельно. По-умолчанию там ставится из стабильных официальных репов 5.6 версия. Но можно установить дополнительно 7ю версию и переключаться между ними. В режиме php-fpm можно запускать сайты параллельно на разных версиях, в режиме модуля апача можно юзать либо ту либо другую, легко между ними переключаться. В режиме CGI тоже можно, но его вообще не стоит юзать. Если только для отладки.

На продакшн ставят то, что нормально работает) Поэтому перед продакшном надо погонять в тестах &#128578; Буквально на прошлой неделе переводил на php 7 как раз самый что ни на есть продакшн — огромную онлайн-библиотеку с трафом 200к в сутки, работающую на кластере из трёх серваков. В паре с разрабом, так задолбались, несколько дней по ночам. Оно работало на debian 7, в который вообще нет технической возможности поставить толком php 7 в режиме апача. Пришлось апгрейдить OS до debian 8, и потом только ставить php 7. Переключить у нас получилось только с третьей попытки, первые две была нестабильность, тормоза, глюки и отвалившийся функционал. Причем, это с учетом того, что до этого было протестировано на PHP 7.

Читайте также:  1845 Код какой страны

По поводу Nginx — да, верно. Можно его использовать без апача в связке с php-fpm. Но обычно под него надо пилить и отлаживать конфиг, редко так сразу заработает. Особенно если какая-то неизвестная CMS или самопис. На основе htaccess пишется такой конфиг. Есть онлайн-конвертеры с .htaccess в правила nginx, но они в чистом редко выдают то что надо. Обычно их просто как подсобный инструмент можно использовать, брать какие-то куски, из них уже лепить и отлаживать свой конфиг.

Веб-серверы могут обрабатывать php-скрипты в разных режимах. Если выбрать подходящий вариант взаимодействия PHP и веб-сервера на сайте, это положительно отразится на его производительности.

Выбрать режим работы 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, поэтому в этом режиме используется циклическая обработка нескольких запросов одним процессом. Это экономит оперативную память за счет сокращения количества запущенных процессов.

Пользователь обладает правами на выполнение всех скриптов на своем www-домене;

Безопасность (каждый запрос выполняется под отдельным пользователем, запуск небезопасного php-скрипта не повлияет на файлы других пользователей, которые находятся на одном с ним сервере);

Каждый пользователь на сервере может выбрать персональную версию PHP;

Отсутствие сбоев сервера при наличии ошибок в скриптах;

Обработка правил конфигурационного файла .htaccess, который поддерживается популярными CMS (WordPress, Joomla, 1C-Битрикс и пр.).

Чуть меньшая производительность по сравнению с модулем Apache;

Медленная обработка статических данных без связки с веб-сервером Nginx.

PHP в режиме FPM

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

Быстрая обработка статических данных;

Отсутствует необходимость в веб-сервере Apache;

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

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

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

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

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