В этой статье я опишу принципиальные различия Apache и Nginx, архитектуру фронтэнд-бэкэнд, установку Apache в качестве бэкэнда и Nginx в качестве фронтэнда. А также опишу технологию, позволяющую ускорить работу веб-сервера: gzip_static+yuicompressor.

. . .

Nginx – сервер легкий; он запускает указанное число процессов (обычно число процессов = числу ядер), и каждый процесс в цикле принимает новые соединения, обрабатывает текущие. Такая модель позволяет с низкими затратами ресурсов обслуживать большое количество клиентов. Однако, при такой модели, нельзя выполнять длительные операции при обработке запроса (например mod_php), т.к. это по сути повесит сервер. При каждом цикле внутри процесса по сути выполняются две операции: считать блок данных откуда-то, записать куда-то. Откуда-то и куда-то – это соединение с клиентом, соединение с другим веб-сервером или FastCGI-процессом, файловая система, буфер в памяти. Модель работы настраивается двумя основными параметрами:

Apache – сервер тяжелый (следует заметить, что при желании его можно достаточно облегчить, однако это не изменит его архитектуры); он имеет две основных модели работы – prefork и worker.

При использовании модели prefork Apache создает новый процесс для обработки каждого запроса, и этот процесс выполняет всю работу: принимает запрос, генерирует контент, отдает пользователю. Настраивается эта модель следующими параметрами:

Эта модель была единственной, которую поддерживал Apache 1.3. Она стабильная, не требует от системы многопоточности, но потребляет много ресурсов и немного проигрывает по скорости модели worker.

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

Основная проблема Apache – на каждый запрос выделен отдельный процесс (как минимум – поток), который к тому же увешан различными модулями и потребляет немало ресурсов. Вдобавок, этот процесс будет висеть в памяти до тех пор, пока не отдаст весь контент клиенту. Если у клиента узкий канал, а контент достаточно объемный, то это может занять длительное время. Например, сервер сгенерирует контент за 0,1 сек, а отдавать клиенту его будет 10 сек, все это время занимая системные ресурсы.

Для решения этой проблемы используется архитектура фронтэнд-бэкэнд. Суть ее в том, что запрос клиента приходит на легкий сервер, с архитектурой типа Nginx (фронтэнд), который перенаправляет (проксирует) запрос на тяжелый сервер (бэкэнд). Бэкэнд формирует контент, очень быстро его отдает фронтэнду и освобождает системные ресурсы. Фронтэнд кладет результат работы бэкэнда в свой буфер и может долго и упорно отдавать его (результат) клиенту, потребляя при этом намного меньше ресурсов, чем бэкэнд. Дополнительно фронтэнд может самостоятельно обрабатывать запросы статических файлов (css, js, картинки и т.д.), управлять доступом, проверять авторизацию и т.д.

Предполагается, что Nginx и Apache у вас уже установлены. Необходимо настроить сервера так, чтобы они слушали разные порты. При этом, если оба сервера установлены на одной машине, бэкэнд лучше вешать только на loopback-интерфейс (127.0.0.1). В Nginx это настраивается директивой listen:

В Apache это настраивается директивой Listen:

Далее нужно указать Nginx проксировать запросы на бэкэнд. Это делается директивой proxy_pass   http://127.0.0.1:81;. Это вся минимальная конфигурация. Однако выше мы говорили, что отдачу статических файлов лучше тоже поручить Nginx. Допустим, что у нас типичный сайт на PHP. Тогда нам нужно проксировать на Apache только запросы к .php файлам, обрабатывая все остальное на Nginx (если ваш сайт использует mod_rewrite, то реврайты тоже можно делать на Nginx, а .htaccess файлы просто выкинуть). Также необходимо учесть, что запрос клиента приходит на Nginx, а запрос к Apache делает уже Nginx, поэтому HTTP-заголовка Host не будет, а адрес клиента (REMOTE_ADDR) Apache определит как 127.0.0.1. Заголовок Host подставить несложно, а вот REMOTE_ADDR Apache определяет сам. Решается эта проблема при помощи mod_rpaf для Apache. Работает он следующим образом: Nginx знает IP клиента и добавляет некий HTTP-заголовок (например X-Real-IP), в который прописывает этот IP. mod_rpaf получает этот заголовок и прописывает его содержимое в переменную REMOTE_ADDR Apache. Таким образом, php-скрипты, выполняемые Apache будут видеть реальный IP клиента.

Теперь конфигурация усложнится. Сначала позаботьтесь, чтобы и в Nginx, и в Apache существовал один и тот же виртуальный хост, с одинаковым корнем. Пример для Nginx:

Теперь задаем настройки для вышеописанной схемы:

Регулярное выражение \.php($|\/) описывает две ситуации: запрос к *.php и запрос к *.php/foo/bar. Второй вариант необходим для работы многих CMS. При запросе example.com/ запрос будет переписан в example.com/index.php (т.к. мы определили index-файл) и также будет проксирован на Apache.

Gzip в Web это хорошо. Текстовые файлы отлично сжимаются, трафик экономится, и контент быстрее доставляется пользователю. Nginx умеет сжимать на лету, так что тут проблем нет. Однако на сжатие файла тратится определенное время, в том числе процессорное. И тут на помощь приходит директива Nginx gzip_static. Суть ее работы в следующем: если при запросе файла Nginx находит файл с таким же именем и дополнительным расширением ".gz", например, style.css и style.css.gz, то вместо того, чтобы сжимать style.css, Nginx прочитает с диска уже сжатый style.css.gz и отдаст его под видом сжатого style.css.

Настройки Nginx будут выглядеть так:

Прекрасно, мы один раз будем генерировать .gz файл, чтобы Nginx много раз его отдал. А дополнительно мы будем сжимать css и js при помощи YUI Compressor. Эта утилита максимально минимизирует css и js файлы, удаляя пробелы, сокращая наименования и т.д.

А заставить все это сжиматься автоматически, да еще и обновляться автоматически можно при помощи cron и небольшого скрипта. Пропишите в cron для запуска раз в сутки следующую команду:

в параметре -P 2 укажите число ядер вашего процессора, не забудьте прописать полный путь к packfile.sh и изменить /var/www на ваш веб-каталог.

В файл packfile.sh пропишите:

не забудьте указать правильный путь к yuicompressor-2.4.2.jar.

Это все, готов выслушать критику :)