Оптимальный PHP-обработчик suPHP

Оптимальный PHP-обработчик suPHP

Какой PHP-обработчик лучше использовать?

Чтобы заработал сайт, построенный на PHP, интерпретатор должен обработать PHP-код и производить генерацию страниц в тот самый момент времени, когда посетитель заходит на сайт или нажимает на гиперссылку. Осуществляется интерпретация кода, базирующегося на библиотеках PHP, имеющихся в системе в данное время, к примеру, PHP 4 или же PHP 5.

Для построения хостинга, сочетающего в себе высокий уровень безопасности и легкую управляемость, разработано немало алгоритмов, концепций и программ. Об одном из этих решений, а конкретнее об использовании технологии mod_suphp мы и поговорим.

Что такое suPHP?

Существует несколько обработчиков, с помощью которых производится загрузка PHP: FastCGI, DSO, CGI и suPHP. Поставка библиотек обработчиками осуществляется через различные реализации и файлы. Любая из этих реализаций оказывает влияние на уровень производительности веб-сервера Apache, так как ее посредством определяется, каким именно образом Apache производит обслуживание PHP.

suPHP – это исполняемый файл, выполняющий функцию оболочки для PHP, в сочетании с модулем mod_suphp веб-сервера Apache. В результате такой совместной деятельности PHP-сценарии могут выполняться с правами владельца, причем двоичный модуль языка PHP не обязательно класть в папку cgi-bin каждого из пользователей. Функция журнализации поддерживается модулем suPHP, а модуль suExec веб-сервера Apache им не используется.

Итак, suPHP дает возможность PHP работать от имени единичного пользователя или же группы пользователей, являющейся владельцем данного веб-сайта, расположенного на разделяемом хостинге. Какую же пользу мы можем извлечь в данном случае? Чтобы разобраться в этом, рассмотрим преимущества данного решения.

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

  • пользовательские процессы находятся в изоляции друг от друга, никто из пользователей не имеет возможности “подсмотреть” данные кого-либо из “соседей”
  • задача создания ограниченного доступа пользователей к системным ресурсам решается с использованием стандартных алгоритмов (/etc/login.conf – классы пользователей), отсутствует необходимость в загрузке дополнительных модулей веб-сервером (за некоторыми исключеними, например, mod_limitipconn)
  • запуск php-скриптов производится через интерфейс cgi
  • изменение параметров конфигурации php не требует перезапуска Apache
  • параметры меняются весьма гибко — можно определить общие, но при этом не являющиеся обязательными параметры, пользователю можно выделить свой собственный php.ini, кроме этого есть возможность указания определенных жестко общих параметров тем пользователям, на которых не имеют влияния параметры из php.ini пользователя

Но, как и стоило ожидать, данное решение обладает не одними лишь достоинствами…

Недостатки suPHP

  • производительность ощутимо ниже, чем у mod_php, хотя, в то же время, гораздо выше, чем у suexec (скорость работы которого ниже в 36 раз)
  • нужно производить установку интерпретатора PHP версии cgi
  • приходится производить сборку собственно mod_suphp

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