Многие говорят, что веб-сервер Apache не обладает достаточной производительностью. Однако, это абсолютно не соответствует действительности. Данное мнение сложилось вследствие искажения оценки объективной особенности Apache – его работу и производительность необходимо скрупулёзно оптимизировать, что не так-то и просто. На самом деле Apache – это очень мощный и очень производительный веб-сервер. Да к тому же ещё так легко масштабируется и адаптируется к различным условиям применения. Однако, это всё в совокупности и является тормозящим фактором, сильно влияющим на производительность. В данной статье речь пойдёт о том, каким образом правильно и эффективно оптимизировать работу и производительность Apache без ущерба выбранной функциональности. Предлагаемые методы являются универсальными, допускается лишь незначительные различия в их реализации, в зависимости от используемой системы Linux.

Отключение неиспользуемых функций и модулей

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

Однако, если наблюдается недостаточная производительность или слишком большое потребление аппаратных ресурсов (как например памяти), следует выяснить, какие модули Apache для текущей конфигурации никогда не используются и даже не актуальны. Например, для современных, даже самых требовательных веб-приложений требуется не более 10-12 модулей. Не говоря уже о среднестатистических сайтах на WordPress или Drupal.

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

Syntax error on line 6 of /etc/apache2/sites-enabled/site-company1:

Invalid command ‘DAVLock’, perhaps misspelled or defined by a module not included in server configuration

Action ‘configtest’ failed

В данном случае Apache использует модуль, который, в свою очередь, не может задействовать функционал, предоставляемый модулем dav_fs, который был отключен.

В Debian-системах, таких как Ubuntu, модули Apache хранятся в каталоге /etc/apache2/mods-available, а список включенных модулей — в каталоге /etc/apache2/mods-enabled. Отключение модуля выполняется путём удаления соответствующего файла в каталоге mods-enabled, либо можно использовать команду:

$ sudo a2dismod mpm_itk

Аналогичным образом работает и команда включения модулей — a2enmod.

Самыми «прожорливыми» модулями Apache, потребляющими довольно много ресурсов системы являются: Rewrite, SSL, Phyton, PHP, Perl. Если они не используются, то конечно, их следует отключать. Либо заменять другими менее требовательными аналогами. Например, модуль Rewrite можно в большинстве случаев заменить модулем Alias.

Оптимизация обслуживания HTTP-запросов

Различные сайты написаны на различных языках программирования. Соответственно, для обслуживания HTTP-запросов к ним и их полноценной работы Apache использует интерпретаторы языков. Взаимодействие веб-сервера и интерпретатора обеспечивается соответствующими модулями. Для PHP это mod_php, а для Ruby – mod_rails. Это «стандартные» модули, предоставляемые базовой поставкой Apache. Однако, они разработаны только с учётом обеспечения дополнительной функциональности без каких-либо решений по оптимизации производительности и потребления ресурсов.

Так, например, модуль mod_php способен потреблять около 100 Мб RAM для работы всего одного процесса, обслуживающего как минимум один HTTP-запрос. Следовательно, чем больше запросов, тем больше потребляемая память только от одного PHP-модуля. В данной ситуации в качестве альтернативы, но уже с куда более оптимизированными производительностью и потреблением памяти существует модуль php-fpm. Этот модуль позволяет обрабатывать HTTP-запросы к веб-приложениям, написанным на PHP, используя технологию Fast CGI. Аналогичными решениями являются uWSGI для Python и Unicorn для Ruby.

Дело в том, что при использовании модуля php-fpm и ему подобных, изначально в памяти создаётся постоянный процесс для интерпретатора PHP ( Python или Ruby). И только после этого происходит перенаправление запросов от Apache к этому процессу для дальнейшей обработки. Таким образом, динамический контент обрабатывается всего двумя процессами. При этом потребление памяти может снизиться более чем в 8 раз.

Ограничение максимального количества процессов Apache

Как было показано выше, один дочерний процесс Apache может использовать 100 Мб RAM и выше. Когда таких процессов слишком много, память системы быстро будет исчерпана и веб-сервер начнёт «тормозить». В конфигурации по-умолчанию для Apache зарезервировано определённое количество процессов, например 30. Для не самого мощного сервера это может быть слишком много. Вообще этот параметр всегда важно тщательно подбирать для конкретной системы.

Для начала важно выяснить, сколько памяти требуется (с небольшим запасом) для корректной и стабильной работы веб-приложения. Затем нужно выделить большую часть свободной памяти веб-серверу. Ситуацию с памятью можно отследить, используя команду top, например:

top -bn 1

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

...

15015 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.02 apache2

15016 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.01 apache2

15017 www-data 20 0 232m 9644 1900 S 0.0 1.6 0:00.02 apache2

Как можно видеть, в системе запущено 3 процесса Apache почти по 10 Мб (столбец RES) каждый. Ели этого много для используемой конфигурации, то целесообразно уменьшить количество процессов для одновременно обрабатываемых запросов. Это делается путём изменения соответствующего параметра (или параметров) работы мультипроцессингового модуля Apache – по-умолчанию это mpm_prefork. В системах Ubuntu соответствующий конфигурационный файл находится в /etc/apache2/mods-available и называется mpm_prefork.conf. Нужно изменить значение параметра MaxClients в соответствии с расчитанным значением объёма RAM, которое можно выделить Apache для данной системы. Например, по-умолчанию это значение обычно 25 — 30. Для не самого мощного сервера можно уменьшить до 15 (и даже меньше):

StartServers 3

MinSpareServers 3

MaxSpareServers 5

MaxClients 15

MaxRequestsPerChild 0

Теперь нужно перезагрузить Apache, чтобы сделанные настройки вступили в силу. Конечно, когда количество клиентов достигнет максимального количества, то пользователь просто получит ошибку сервера. Однако, он всегда может перезагрузить страницу и снова получить доступ к серверу (веб-приложению). Поскольку ограничение обслуживающих процессов не позволяет превысить лимит памяти, отведённой Apache, то это никак не скажется на его производительности. Ведь памяти всегда хватает. Это не совсем «демократично» по отношению к пользователям. Однако это лучше, чем бесконечно поддерживать «тормозящие» или полузависшие процессы Apache.

Использование альтернативных мультипроцессинговых модулей

Здесь нет чётких рекомендаций относительно того, кокой именно мультипроцессинговый модуль и для какой конфигурации использовать. Одни из них экономят процессорное время, другие — использование RAM.

Например, по-умолчанию Apache использует универсальный модуль mpm-prefork. Который работает практически со всеми интерпретаторами (PHP, Ruby и т. д.). Однако в качестве альтернативы можно использовать модуль mpm-worker. Который обладает более производительной стратегией управления дочерними процессами. Но данный модуль не поддерживает работу с интерпретаторами PHP и Ruby через стандартные внешние модули, такие как mod-php. Поэтому выбор мультипроцессингового модуля Apache – это очень выверенное и обдуманное решение.

Заключение

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