Apache против nginx: плюсы и минусы для wordpress

Родные

Обзорная таблица

Поддержка платформ

IndiMail

Название: IndiMail

Сайт проекта: indimail.sf.net

Лицензия: GNU GPL

Платформа: *nix

Веб-интерфейс iWebAdmin построен на QmailAdmin

Платформа обмена сообщениями по протоколам SMTP, IMAP, POP3, поддерживающая QMQP, QMTP, DKIM и BATV (Bounce Address Tag Validation) и проверку почты на спам и вирусы. Базируется на нескольких Open Source решениях: Qmail, Courier IMAP/POP3, serialmail (доставка почты через коммутируемые соединения), qmailanalog (списки рассылки), dotforward, fastforward, mess822, daemontools, ucspi-tcp, Bogofilter, Fetchmail и других. Предоставляет набор инструментов для управления виртуальными доменами и учетными записями пользователей собственной разработки. Обеспечивает маршрутизацию для SMTP, IMAP и POP3, что позволяет разместить почтовый домен на нескольких серверах с обменом данными между ними или как прокси. Это очень удобно, если организация состоит из нескольких удаленных офисов. Используя утилиту hostcntrl, можно добавить на обслуживание отдельные адреса из других доменов. Это позволяет использовать IndiMail в гетерогенной среде без необходимости поднятия нескольких доменов или при переходе от проприетарного решения. Несколько серверов с синхронизацией данных позволяют легко наращивать структуру. Чтобы обеспечить лучшую масштабируемость и производительность, некоторые компоненты были изменены (в частности, Qmail). В IndiMail используется несколько так называемых коллекций (queue collection), каждая из которых выполняет свой процесс qmail-send/qmail-todo и может хранить данные на отдельном харде. Такая архитектура позволяет обрабатывать запросы быстрее, чем оригинальный Qmail.

Разработчики дают полную свободу в настройках, практически все параметры можно переопределить через переменные (а их всего около 200). Например, переменная CONTROLDIR указывает на каталог с конфигурационными файлами, QUEUEDIR — каталог с очередями. То есть можно запустить несколько копий IndiMail на одном сервере со своими настройками для каждой очереди, отправителя, получателя и узла. Но разбираться во всех переменных необязательно: чтобы запустить IndiMail, понадобится всего несколько правок. Новички могут управлять установками при помощи меню FLASH (построено на Ncurses). Для хранения данных о виртуальных пользователях используется MySQL, адресные книги могут храниться в OpenLDAP. Последние релизы полностью совместимы с systemd. Много внимания разработчики уделяют безопасности как самого сервера, так и сервисов — минимальное использование SETUID, четкое разделение между программами/адресами/файлами, пятиуровневый trust partitioning, автоматическое распознавание локальных IP, access-list, tcprules, фильтр контента, TLS/SSL и многое другое.

Установить IndiMail можно на любой 32/64 *nix платформе. Для загрузки доступны исходные тексты, пакеты и репозитории для некоторых популярных дистрибутивов Linux (RHEL/CentOS 5/6, Fedora, openSUSE/SLE, Mandriva, Debian и Ubuntu). Для управления сервером предлагается около 45 программ различного назначения (большинство расположено в /var/indimail/bin), учетные записи можно также настраивать при помощи веб-интерфейса iWebAdmin (построен на QmailAdmin), который необходимо устанавливать отдельно.

Оптимизация PHP

Зачастую наибольшая нагрузка создается вовсе не HTTP-сервером, а интерпретатором языка программирования, используемого для создания динамического содержимого веб-сайта

Сегодня наиболее популярным языком для серверного веб-скриптинга является PHP, поэтому именно ему мы уделим внимание в нашей статье. Открываем файл /etc/php5/ apache2/php.ini (путь для Ubuntu, в других дистрибутивах может быть иным) и редактируем следующие строки:

• memory_limit — лимит на съедаемую при генерации веб-страницы память. Перед изменением этого параметра рекомендуется выполнить соответствующие замеры и основывать значение уже на их результатах.
• display_errors = Off, error_log = /var/log/php — перенаправлять сообщения об ошибках в log-файл. Включай этот параметр тогда, когда все скрипты будут полностью отлажены.
• upload_max_filesize и post_max_size — максимальный размер загружаемых файлов и POST-запросов. Опять же, значение должно быть выбрано исходя из потребностей твоего веб-приложения.

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

Установка memcached

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

1. Устанавливается memcached:

2. В секцию server конфигурационного файла nginx добавляе тся примерно следующее:

3. Для PHP устанавливается расширение memcache (клиент к memcached):

4. В страницы встраивается примерно такой код:

Все это отлично работает, но только в отношении очень простых, почти статических веб-сайтов. Дело в том, что страница не всегда должна быть одинаковой для всех посетителей. Что если главная страница будет закэширована при входе на сайт гостя, а после него на сайт придет зарегистрированный участник, которому вновь предложат зарегистрироваться.
Непорядок. Однако есть достаточно простой выход из этой ситуации. Проблему может решить покрытая мхом и паутиной технология под названием SSI (Server Side Includes). SSI позволяет разбить веб-страницу на несколько блоков, которые будут собраны фронт-эндом воедино в момент обработки запроса клиента. Например, используя SSI, ты делишь главную страницу веб-сайта на две части:

Это ровно та же страница, код аутентификации которой вынесен в файл auth.php, а вся остальная часть — в body.php. Изюминка же заключается в том, что приведенный выше в четвертом шаге код кэширования ты помещаешь только во второй из этих файлов. Как результат вырисовывается следующая картина:

1. Человек приходит на сайт в первый раз. Происходит запрос главной страницы веб-сайта к nginx.
2. Сервер nginx запрашивает файл index.php у бэк-энда (Apache), встречает внутри него SSI-директивы и делает еще *2* запроса к бэк-энду (auth.php и body.php).
3. Получив запросы, Apache запускает PHP-интерпретатор для обработки запрашиваемых файлов, в результате чего (кроме всего прочего) содержимое тяжелого файла body.php попадает в кэш memcached.
4. Ответ возвращается nginx, который объединяет файлы в один index. php и отдает их клиенту.
5. После этого на сайт приходит зарегистрированный участник, происходит запрос index.php у бэк-энда (хотя, скорее всего, он будет взят из кэша самого nginx), однако к Apache уйдет только запрос простого и легкого auth.php, тогда как body.php будет взят из кэша memcached.

Само собой разумеется, SSI необходимо активировать в конфигурационном файле nginx с помощью опции «ssi on», помещенной в секцию «location /». Стоит отметить, что блок auth.php также поддается кэшированию, но для этого придется присваивать всем зарегистрированным пользователям идентификатор, сохранять его в кукисах и использовать для генерации уникального ключа memcached.

Установка nginx

Будучи популярным, большой динамический веб-сайт может создать такую нагрузку на сервер, что Apache начнет «захлебываться и плеваться».

И дело тут даже не в том, что железо не позволяет, а в тяжеловесности самого HTTP-сервера. Apache отлично подходит для отдачи динамического контента, однако большая часть современных веб-страниц так или иначе состоит из статики, и использовать для их отдачи мощный, сложный и очень тяжелый HTTP-сервер было бы так же глупо, как ездить на вездеходе по дорогам Швейцарии. Мы воспользуемся легковесным HTTP-сервером Nginx для разгрузки Apache и его освобождения от неблагодарного занятия отдачей статического контента. В отличие от Apache, Nginx использует событийную модель обработки запросов, благодаря чему на любое количество клиентов требуется всего один процесс HTTP-сервера.

Это существенно снижает нагрузку на железо, но создает определенные проблемы при обработке динамического контента (именно поэтому его не используют в качестве основного HTTP-сервера). Обычно Nginx устанавливают на выделенную машину, которая смотрит во внешнюю сеть и выступает в качестве первого чекпоинта на пути следования запросов, однако допустим и вариант с одним физическим сервером, когда Apache и Nginx крутятся на одной машине. Остановимся на нем. Открываем файл /etc/apache2/ports.conf и изменяем две опции:

Создаем конфиг нашего хоста:

Все, перезапускаем Apache и Nginx:

Оптимизация Apache

Корневой компонент большинства современных веб-сайтов — это, конечно же, Apache. Он зарекомендовал себя как наиболее функциональный, стабильный и удобный в использовании HTTP-сервер, который можно использовать как для обслуживания домашней веб-страницы, так и для высоконагруженных корпоративных интернет-проектов. Одна проблема: Apache — очень тяжелое приложение, жадное до ресурсов сервера.

И это должно быть учтено при его настройке. Вот список рекомендаций, которые лучше выполнять при подготовке HTTP-сервера к работе:

• Львиная доля функционала Apache вынесена в загружаемые модули, которые можно активировать или отключить путем редактирования конфигурационного файла (директива LoadModule). Хорошей практикой является тотальное отключение всех неиспользуемых модулей, что позволит повысить производительность сервера и сохранить оперативную память.
• Apache обрабатывает каждый новый запрос в собственном потоке исполнения и позволяет использовать разные подходы для выполнения этой операции. Если ты собирал Apache2 из исходников, то мог заметить, что в опциях сборки присутствует возможность выбора так называемого MPM. Это и есть модуль мульти-процессинга (Multi-processing module), используемый для распараллеливания HTTP-сервера.

Всего их существует три:

1. prefork — классический MPM, реализующий модель мульти-процессинга, используемую в Apache 1.3. Каждый поток обрабатывается в отдельном процессе. Не самый производительный вариант, но наиболее стабильный. Используется по умолчанию.
2. worker — MPM, основанный на потоках. Сервер порождает несколько процессов, по несколько потоков в каждом. Один запрос — один поток. Производительнее prefork, но менее стабилен.
3. event — событийный MPM. Вместо потоков запросы обрабатываются, используя событийную модель, похожую на ту, что применяется в nginx. Наиболее производительный MPM, но и наименее стабильный (находится в экспериментальной стадии разработки).

Многие дистрибутивы позволяют устанавливать разные варианты Apache, различающиеся используемым MPM, их легко можно найти в репозитории по запросу «apache2-mpm».

• Apache позволяет контролировать максимальное количество порождаемых потоков с помощью опции MaxClients. Не стоит устанавливать ее значение слишком большим, иначе в определенный момент сервер исчерпает всю оперативную память, начнет свопить, и необслуженными останутся гораздо больше клиентов, чем было бы при задании жесткого ограничения. Оптимальным считается значение, равное количеству памяти, доступной Apache, поделенное на максимальный размер порожденного потока (проверяется с помощью ps или top).
• Как и многие другие HTTP-серверы, Apache позволяет контролировать длительность удержания соединений типа keep-alive, используемых для передачи нескольких запросов/ответов в рамках одного соединения. Keep-alive позволяет экономить ресурсы сервера, не вынуждая его создавать отдельный поток на каждую картинку, CSS и прочие элементы страницы. Однако слишком долго такое соединение держать открытым не стоит, потому как на это тоже уходят ресурсы. Хорошим значением опции KeepAliveTimeout будет 5-10 секунд, причем, если все зависимые компоненты страницы отдаются клиенту отдельными серверами, а текущий сервер используется только для отдачи HTML/PHP, необходимость поддержки keep-alive отпадает вовсе, и значение опции KeepAlive лучше установить в Off.
• Apache не любит сжатие. Если ты решил увеличить скорость отдачи страниц с помощью сжатия, то имей в виду, что, скорее всего, оно создаст еще большую нагрузку на сервер. Если же сжатие действительно необходимо (например, для мобильного портала, основной поток клиентов которого использует канал GPRS), то устанавливай коэффициент сжатия минимальным, это приведет лишь к незначительному росту объема результирующих данных, зато позволит существенно сэкономить ресурсы сервера.

Установка Eaccelerator

PHP — язык интерпретируемый. Это значит, что каждый раз, когда происходит вызов скрипта на этом языке, запускается PHP-интерпретатор, который проводит полный анализ исходного кода. Причем, если спустя секунду произойдет второй запуск того же скрипта, вся процедура будет повторена заново. Это нерациональное использование ресурсов, поэтому мы применим инструмент под названием eAccelerator, который скомпилирует исходные тексты PHP в двоичное представление, оптимизирует их и будет бережно хранить в оперативной памяти для более быстрого доступа. Благодаря только этому скорость обработки PHP-скриптов вырастет в десятки раз (подтверждено тестами).

Пакета eAccelerator нет в репозиториях популярных дистрибутивов, поэтому его придется собрать самостоятельно. Сначала устанавливаем необходимые для сборки утилиты:

Далее получаем исходные тексты eAccelerator:

Создаем каталог для хранения кэша: