Настройка веб-сервера

Настройки «по умолчанию» - это далеко не всегда хорошо. На них можно начать работать, но с ними трудно обеспечить нужную производительность и надёжность. Однако неграмотное изменение настроек по умолчанию может дать обратный результат: не ускорение, а замедление работы. Типовые ошибки конфигурации:

• PHP как CGI (не путать с FastCGI). В этом случае на каждый хит запускается собственный процесс, который делает какую-то обработку, а потом гасится. Ресурсоёмкая и долгая операция, проект при такой настройке будет работать непроизводительно.
• Использование параметра open_basedir в PHP, который призван изолировать клиентов на сервере друг от друга. Этот параметр не панацея в плане безопасности, и он существенно снижает производительность.
• Не установлен прекомпилятор PHP на хостинге. Часто его нужно включать самостоятельно. Прекомпилятор интерпретирует php скрипт в байткод, обрабатывается и сохраняет в кеше. В последующем интерпретация не требуется, байткод получается из кеша. Прекомпилятор снижает нагрузку на процессор и ускоряет исполнение php скриптов.
• Недостаточно памяти прекомпилятору, в результате кеш для прекомпилированных скриптов будет работать крайне неэффективно на больших проектах.
• Медленная файловая система и/или мало дискового кэша.
• Отсутствует FrontEnd (NGINX). Подробнее смотрите в курсе для хостеров
• NGINX есть, но всю статику запрашивает у Apache.
• Не отрегулировано значение MaxClients в Apache.

Прекомпиляторы

Их надо использовать. Один из самых быстрых - Zend Optimizer+, правда он и один из самых непрозрачных. APC на 5-10% медленнее, но надёжнее, реже падает, и работать с ним проще.

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

Можно ли без Apache? PHP-FPM

Возможно использование вместо Apache модуля PHP-FPM. Этот вариант обладает с одной стороны неудобством: если у вас много логики, завязанной на файл .htaccess , то эту логику надо перенести отдельно в конфиг NGINX. Это делается один раз, но потом останутся только удобства.

Пример конфига:

location ~ \.php$ {
   root /var/www/chroot/var/www/html;
   fastcgi_intercept_errors on;
   fastcgi_pass    backend;
   fastcgi_index  index.php;
   include        fastcgi_params;
   fastcgi_param  DOCUMENT_ROOT  /var/www/html;
   fastcgi_param  SCRIPT_FILENAME /var/www/html/$fastcgi_script_name;
   fastcgi_param  SERVER_NAME  $host;
   fastcgi_split_path_info  ^(.+\.php)(.*)$;
   fastcgi_param PATH_INFO  $fastcgi_path_info;
}

Apache при каких-то ошибках не умеет сам себя рестартовать, нужны внешние обработчики. А на больших нагрузках достаточно часто могут возникать ошибки вида segmentation fault. PHP-FPM может делать рестарт внутренними средствами:

; рестартовать при ошибках
emergency_restart_threshold = 1
emergency_restart_interval = 10

Первое - количество ошибок за интервал времени, после которого надо перезапустить сервер;
второе - тот самый интервал.

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

Пример конфига:

pm = static
pm.max_children = 30
pm.start_servers = 30
pm.min_spare_servers = 30
pm.max_spare_servers = 30

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

request_slowlog_timeout = 5
slowlog = /opt/php/var/log/www.slow_access.log

Лог медленных запросов - самый простейший инструмент увидеть проблемные места быстро. В идеале лог должен быть пустым, либо в нём должны быть запросы, о которых вам известно и которые вы допускаете быть долгими.

PHP-FPM очень хорошо подходит для ограничения прав доступа, если на одном сервере работает несколько проектов. В этом случае для каждого проекта можно выделить свой пул, выделить свой chroot. В отличие от open_basedir, он никаким образом не снижает производительность, успешно разделяя пользователей.

; не open_basedir в php.ini
chroot = /var/www/chroot

Более того, можно задать разные пулы, разные конфигурации под разные сервера.

  Чек-лист по настройке

Примерный чек-лист, который должен быть выполнен при настройке веб-сервера:

• Стабилизировать систему по памяти.
• Обеспечить надёжность системы при возрастающей нагрузке - обслуживается максимум запросов, остальные ожидают в очереди.
• Использовать persistent connections для базы при установленном фиксированном числе процессов.
• Использовать frontend для отдачи статики.
• Не занимать backend медленными запросами клиентов.
• Использовать сжатие - быстрее отдавать на медленных каналах.
• Разгрузить процессор за счет прекомпиляции PHP.