PHP, на сегодняшний день, это одна из самых популярных платформ для создания Web приложений. Нет смысла в очередной раз упоминать о многочисленных монстрах современного интернет, основой которых служит PHP.

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

В этой статье мы рассмотрим общие практики и советы при построении нагруженных систем на основе PHP.

Связка с Web сервером

Существует несколько способов связать PHP с Web сервером:

CGI

CGI - стандартный протокол для запуска приложений в связке с Web сервером. Суть его заключается в следующем:

1. Запрос приходит к Web серверу
2. Сервер запускает php-cgi
3. Исполняется основное приложение и генерируется HTTP ответ
4. Ответ передается Web серверу и php-cgi процесс уничтожается

Этот подход весьма ресурсоемкий, т.к. приходится создавать процессы php-cgi при каждом запросе.

FastCGI

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

SAPI

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

Исходя из этого, наиболее оптимальным решением для крупных систем является использование протокола FastCGI. Это удобное, гибкое и производительное решение.

Прекомпилирование и оптимизация

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

Существует несколько технологических решений этой проблемы:

eAccelerator

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

APC

Помимо кеширования промежуточного кода, APC предоставляет еще и функционал по доступу к разделяемой памяти (что является очень эффективным средством для кеширования). Официальный сайт.

Zend Platform

Это многофункциональное платное решение от Zend. Помимо кеширования кода и оптимизации исполнения, этот продукт позволяет кешировать данные/контент, оптимизировать загрузку и использовать преимущества асинхронной обработки. Официальный сайт.

Настройка PHP

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

Есть ряд стандартных параметров PHP о которых стоит упомянуть:

• memory_limit - не стоит устанавливать этот параметр слишком большим. Если Ваша страница съедает по 512 Мб памяти во время генерации, то Вам стоит задуматься об архитектурных изменениях. Значения в 32…64Мб должно быть достаточно.
• display_errors = Off и error_log = /var/log/php - это скорее обязательное требование для продуктивной среды, чем совет. Эти настройки отключают вывод ошибок на экран и собирают их в лог файл.
• upload_max_filesize и post_max_size - максимальный размер загружаемых файлов и POST запросов - удостоверьтесь, что эти параметры не крупнее, чем требуется для Вашего приложения. Если Вы не используете загрузку - выключите ее: file_uploads = Off
• zlib.output_compression = Off и zlib.output_compression_level = -1 - включите компрессию контента. На первый взгляд компрессия будет расходовать дополнительные ресурсы процессора, но она позволяет добиться существенно меньших размеров ответа (ощутимо для посетителя). К тому же, компрессия на бекендах позволяет экономить ресурсы фронтенд-серверов.

Я что-то забыл? Что я забыл?

Статьи по теме

• Настройка и оптимизация параметров postgresql
• Тюнинг FreeBSD 7 под высокие нагрузки