Оптимизация производительности веб-сервера Apache

Apache web server performance optimization

Dmitry Pekshev

master student, Ryazan State Radio Engineering University, Russian Federation, Ryazan

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

Abstract. The article describes various ways to optimize the performance of the Apache web server, to increase the speed of web site maintenance.

Ключевые слова: веб-сервер, настройка веб-сервера, оптимизация, конфигурирование, увеличение производительности.

Keywords: web server, web server setup, optimization, configuration, performance increase.

Как известно, наличие большого количества аппаратных ресурсов является обязательным для работы эффективного веб-сервера. Быстрый процессор и большой объем оперативной памяти являются основными потребностями для высокоскоростного веб-сервера Apache. Но невозможно гарантировать хорошую производительность только за счет современного оборудования или путем добавления большего количества оперативной памяти или заменив процессор. Apache представляет широкие возможности для настройки. Неправильно настроенный сервер может свести на нет преимущества его высокопроизводительных комплектующих.

HTTP-сервер Apache - это модульная программа, в которой администратор может выбрать функциональные возможности для включения в сервер, выбрав набор модулей. Модули могут быть либо скомпилированы статически в билд httpd, либо как динамические общие объекты (DSO). Настоятельно рекомендуется запускать Apache только с необходимыми модулями. Это уменьшает объем памяти и, следовательно, производительность сервера. Статически компилируемые модули будут сохранять ОЗУ, которая используется для поддержки динамически загружаемых модулей, но нужно перекомпилировать Apache всякий раз, когда модуль должен быть добавлен или удален. Именно здесь механизм DSO пригодится. Оптимальным решением будет составить список всех действительно используемых модулей и сохранить его. Затем следует просто отключить один за другим модули не входящие в список.

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

Если сервер обслуживает сайты на PHP, то наверняка используется знаменитый mod_php. Если сайт на Ruby, используется mod_rails или mod_rack. Их проблема в том, что код C для интерпретатора для этих языков встроен в Apache, тем самым используя больше памяти для каждого просмотра страницы. Если популярная страница сайта вызывает 30 HTTP-запросов, одна из них будет для динамической страницы, а другие 29 - для статических ресурсов, таких как изображения, css и javascript. Зачем использовать все возможности Apache для тех 29 запросов, которые не обслуживают какой-либо динамический контент? PHP может воспользоваться php-fpm, который представляет собой отдельный процесс, который использует протокол fastcgi, для Python используем uWSGI или gnunicorn, для Rails используйте Unicorn. Обычно происходит то, что запускается специальный серверный процесс для PHP или Python или Ruby, а затем Apache, зная как справляться с этими запросами через встроенный код, просто перенаправляет вызов динамического контента на один из выше перечисленных процессов.

Большинство конфигураций Apache для разных операционных систем не подходят для небольших серверов с относительно небольшим объемом оперативной памяти, потому что обычно используют 25 дочерних процессов или более. Если каждый из дочерних процессов потребляет 120 МБ ОЗУ, то потребуется 3 ГБ только для Apache. Веб-браузер одного посетителя запрашивает как минимум сразу 4 элемента на веб-сайте, поэтому если 10 человек попытаются загрузить страницу одновременно, то сервер может быть полностью загружен, а запросы будут накапливаться в очереди. Часто бывает, что сервер будет держать эти мертвые процессы активными, пытаясь обслуживать их еще какое-то время после того, как пользователь уже передумал ждать их завершения, что уменьшает количество полезных процессов, доступных для обслуживания, и уменьшает объем доступной системной памяти. Что в таком случае лучше сделать, так это выяснить, сколько оперативной памяти требуется конкретному веб-приложению, а затем узнать, сколько осталось, и выделить большую часть этого под Apache.

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

Директива под названием MaxClients устанавливает ограничение на максимальное количество одновременных запросов, которые могут поддерживаться сервером. Ее нельзя устанавливать слишком низкой, чтобы новые запросы помещались в очередь, что в конечном итоге заканчивается тайм-аутом, а ресурсы сервера при этом оставались неиспользованными. Слишком высокое значение приведет к тому, что сервер будет производить частую замену очереди, и время отклика резко ухудшится. Оптимальное значение для MaxClients можно рассчитать как: MaxClients = количество RAM, выделенное для веб-сервера / максимальный размер дочернего процесса. Если пользователей одновременно отправляющих запросы больше, чем MaxClients, запросы будут помещены в очередь под номером, основанным на директиве ListenBacklog.

Директивы MaxSpareServers и MinSpareServers определяют, сколько дочерних процессов нужно поддерживать в ожидании запросов. Если MinSpareServers слишком низок, и приходит множество запросов, тогда Apache придется создавать дополнительные процессы для обслуживания запросов. Создание дочерних процессов относительно ресурсоемко. Если сервер занят их созданием, он не сможет немедленно обслуживать запросы клиентов. MaxSpareServers не следует устанавливать слишком высоко, это может вызвать проблемы с распределением ресурсов, опять таки из-за дочерних процессов, которые потребляют значительные ресурсы. Следует настроить MinSpareServers и MaxSpareServers таким образом, чтобы Apache не должен был порождать более 4 дочерних процессов в секунду (по документации, Apache может породить максимум 32 дочерних процесса в секунду).

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

Директива KeepAlive позволяет отправлять несколько запросов по одному и тому же TCP-соединению. Это особенно полезно при обслуживании HTML-страниц с большим количеством изображений. Если для KeepAlive установлено значение выключено, то для каждого изображения необходимо создать отдельное TCP-соединение. Накладные расходы из-за установления TCP-соединения можно устранить, включив KeepAlive. Директива KeepAliveTimeout определяет, как долго ждать следующего запроса. Разумно установить ее на низкое значение, возможно, от двух до пяти секунд.

Еще один способ увеличить производительность веб-сервера это использование HTTP-сжатия. Оно полностью поддерживается протоколом HTTP 1.1 и описано в его спецификациях. Использование сжатия позволит сэкономить полосу пропускания и улучшить время отклика. Исследования показывают средний коэффициент сжатия трафика 75,2%. Сжатие HTTP можно включить в Apache, используя модуль mod_deflate. Трафик сжимается только в том случае, если браузер запрашивает это, иначе подается несжатый контент.

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