Я использую APC для кода операции в соответствии с лицензией Litepeed с 4-мя процессорами. Каков лучший обработчик PHP для этой ситуации с точки зрения производительности в первую очередь, а позже – безопасности?
Это suphp / dso / fcgi / cgi? (я читал, что DSO может оставить отверстие, если у одного из скриптов есть ошибка)?
myusername@mybox [~]# /usr/local/cpanel/bin/rebuild_phpconf --available Available handlers: suphp dso fcgi cgi none PHP4 SAPI: cgi PHP5 SAPI: not installed SUEXEC: available RUID2: not available Спасибо.
Об этом в блоге Servint есть отличная статья: http://blog.servint.net/2011/10/28/the-tech-bench-all-about-php-handlers/
Не забудьте посетить там сайт, он также имеет сравнительные диаграммы.
Список обработчиков PHP
DSO
Также известен как mod_php. Хотя это более старая конфигурация, ее основным преимуществом является скорость. Обычно считается самым быстрым обработчиком. Он запускает PHP непосредственно из Apache, не передавая его отдельной службе для обработки. Это означает, что скрипты PHP будут выполняться как пользователь Apache, который по умолчанию на наших серверах является пользователем «nobody».
Перед переключением на DSO есть две вещи. Во-первых, для любых файлов, которые должны быть записаны веб-сервером, должны быть права на запись для пользователя «nobody», а любой файл, созданный веб-сервером, будет принадлежать «nobody». Веб-сайты, которые должны загружать файлы через PHP, могут возникать при проблемах с разрешениями, поскольку настройки не столь четкие, как другие обработчики. Это характерно для пользователей WordPress, которые загружают файлы через интерфейс WordPress или используют функцию автоматического обновления.
Особое примечание об этом: распространенное заблуждение, что файлы должны иметь режим 777 для записи. Это неверно, и, как правило, это плохая идея, поскольку это означает, что файлы могут быть доступны для записи кем угодно. Чтобы сделать файл доступным для записи веб-сервером, необходимы самые высокие разрешения 664 и принадлежат «пользователю» и группе «никто». Для каталогов это будет 775, а пользователь: никто. Этого должно быть достаточно, чтобы веб-сервер мог писать в локацию, не делая его доступным для записи всем и представляя потенциально критическую уязвимость системы безопасности.
Кроме того, знайте, что DSO предлагает другой тип безопасности, а не suPHP / FastCGI. Поскольку сервер запускает его как «никто», любой, кто сможет использовать файл на вашем сервере для получения повышенных прав, будет иметь доступ к любому другому файлу, к которому веб-сервер может напрямую обращаться. Это просто означает, что злоумышленник может иметь доступ к файлам через несколько учетных записей, а только к тем файлам, которые принадлежат «никому». Дополнительную информацию см. В разделе «Безопасность» ниже.
Основным преимуществом DSO является скорость и использование ресурсов. С расширениями кэширования кода операций, такими как eAccelerator или APC, DSO будет работать значительно быстрее и с меньшим размером, чем другие обработчики. Это также значение по умолчанию на наших серверах.
Хорошим правилом является то, что DSO лучше всего подходит для серверов, на которых работает один или два больших высокопроизводительных веб-сайта, на которых эффективность и скорость вызывают беспокойство.
CGI
Обработчик CGI будет запускать PHP как модуль CGI, а не модуль Apache. Метод CGI предназначен как резервный обработчик, когда DSO недоступен. Этот метод не является ни быстрым, ни безопасным, независимо от того, включен или нет suEXEC. Поэтому ServInt не рекомендует использовать CGI.
suPHP
suPHP запускает PHP как отдельную службу, которая затем передает скомпилированный код обратно в Apache для обслуживания. Это технически модуль CGI, однако он сильно отличается от обработчика CGI, упомянутого выше. Основное отличие и преимущество использования suPHP заключается в том, что при использовании suEXEC он запускает скрипты PHP как пользователь, вызывающий их, а не как пользователь «nobody». Например, если учетная запись принадлежит пользователю Spock, все экземпляры Apache, обслуживающие этот веб-сайт пользователя, будут выполняться как пользователь Spock. Преимущество здесь в том, что он упрощает отслеживание веб-сайтов с использованием избыточных ресурсов.
Еще одним преимуществом запуска процесса в качестве пользователя является упрощение общей схемы разрешений. Веб-сервер сможет записывать файлы, принадлежащие пользователю, а не только «никто». В долгосрочной перспективе это означает, что функции автоматического обновления / установки во многих решениях CMS будут работать более легко, а общие разрешения вашего файла / каталогов более четкие: 644 и принадлежат пользователю и пользователю группы для файлов, и аналогично 755 и пользователь: пользователь для каталогов.
Разница в безопасности между suPHP и DSO заключается в том, что suPHP ограничивает злоумышленника конкретному пользователю, которого он / она затронул. Эксплойт не может перекрещивать учетные записи, однако он может влиять на каждый отдельный файл, который принадлежит пользователю, а не только файлы, доступные для записи веб-сервером. Дополнительную информацию см. В разделе «Безопасность» ниже.
Основным недостатком suPHP является скорость и загрузка процессора. suPHP работает намного медленнее, чем другие обработчики, и вы увидите значительное увеличение общей загрузки процессора при переключении на него. suPHP также не может работать с расширением кэширования кода операции, например, eAccelerator или APC, что является причиной увеличения использования ЦП. Из-за этого рекомендуется внедрить плагин кеширования, если вы используете его с CMS, например W3-Total-Cache для WordPress. Этот обработчик рекомендуется больше для меньшего клиента реселлера. Это связано с тем, что он блокирует эксплойты одной затронутой учетной записи, а увеличение загрузки ЦП не будет значительным с менее загруженными сайтами или небольшим количеством отдельных учетных записей cPanel.
FastCGI
FastCGI (aka: mod_fcgid) похож на suPHP, поскольку он представляет собой отдельный процесс, который компилирует PHP, который затем отправляется обратно в Apache. Это также модуль CGI, что означает, что с помощью suEXEC PHP работает как пользователь. Это дает вам те же преимущества разрешений suPHP, о которых говорилось выше. Однако разница между ними заключается в том, как они контролируют процессы PHP. suPHP запускается каждый раз, когда необходимо скомпилировать PHP-процесс, тогда как FastCGI сохраняет открытые соединения открытыми, которые могут быть вызваны одним и тем же процессом PHP. Это позволяет использовать расширение кэширования кода операции, например eAcceleartor или APC, для повышения производительности.
Недостатком является то, что FastCGI имеет высокую память. Из-за постоянных соединений, упомянутых выше, которые хранятся в памяти, вы увидите гораздо более доступную память, используемую FastCGI.
Хорошая аналогия FastCGI и suPHP – это книга с несколькими главами. С suPHP эта книга не будет содержать оглавления и индекса, поэтому каждый раз, когда вы хотите найти что-то, вам нужно просмотреть книгу, чтобы получить ее. Это требует времени (увеличение использования ЦП) и медленное. В FastCGI эта книга содержит обширный указатель и оглавление, поэтому вы можете быстро и легко найти то, что ищете; однако эти дополнительные страницы делают книгу намного толще (увеличение использования памяти).