Apache настройка · 9 min read · Jan 26, 2026
Настройка Apache для максимальной производительности
Apache — это реализация HTTP-сервера с открытым исходным кодом. Это самый популярный веб-сервер в Интернете. Опрос веб-серверов в декабре 2005 года, проведенный Netcraft [
1 ] показывает, что около 70% веб-сайтов в Интернете используют Apache.
1. Производительность сервера Apache
Производительность сервера Apache можно улучшить, добавив дополнительные аппаратные ресурсы, такие как ОЗУ, более быстрый процессор и т. д. Но, чаще всего, тот же результат можно достичь с помощью индивидуальной настройки сервера. Эта статья рассматривает, как получить максимальную производительность от Apache с существующими аппаратными ресурсами, в частности на системах Linux. Конечно, предполагается, что есть достаточно аппаратных ресурсов, особенно достаточно ОЗУ, чтобы сервер не использовал свопинг слишком часто. Первые два раздела рассматривают различные параметры конфигурации времени компиляции и времени выполнения. Раздел времени выполнения предполагает, что Apache скомпилирован с использованием
prefork
MPM. Далее обсуждаются HTTP-сжатие и кэширование. Наконец, обсуждается использование отдельных серверов для обслуживания статического и динамического контента. Предполагается базовое знание компиляции и настройки Apache и Linux.
2 Параметры конфигурации времени компиляции
2.1 Загружайте только необходимые модули:
Сервер Apache HTTP — это модульная программа, где администратор может выбрать функциональность, которую следует включить в сервер, выбрав набор модулей [
2 ]. Модули могут быть либо статически скомпилированы в бинарный файл httpd, либо могут быть скомпилированы как динамические общие объекты (DSO). Модули DSO могут быть скомпилированы, когда сервер создается, или могут использовать утилиту
apxs
для компиляции и добавления позже. Модуль mod_so должен быть статически скомпилирован в ядро Apache, чтобы включить поддержку DSO.
Запустите apache только с необходимыми модулями. Это уменьшает объем используемой памяти и, следовательно, производительность сервера. Статическая компиляция модулей сэкономит ОЗУ, используемую для поддержки динамически загружаемых модулей, но необходимо будет перекомпилировать Apache каждый раз, когда модуль нужно добавить или удалить. Вот где механизм DSO оказывается полезным. Как только модуль mod_so будет статически скомпилирован, любой другой модуль можно добавить или удалить с помощью команды LoadModule в файле httpd.conf — конечно, вам придется скомпилировать модули с помощью apxs, если они не были скомпилированы, когда сервер был создан.
2.2 Выберите подходящий MPM:
Сервер Apache поставляется с набором многопроцессорных модулей (MPM), которые отвечают за привязку к сетевым портам на машине, принятие запросов и распределение дочерних процессов для обработки запросов [
3 ]. В любой момент времени в сервер можно загрузить только один MPM.
Выбор MPM зависит от различных факторов, таких как поддерживает ли ОС потоки, сколько памяти доступно, масштабируемость по сравнению со стабильностью, используются ли небезопасные для потоков сторонние модули и т. д. Системы Linux могут выбрать использование многопоточного MPM, такого как worker, или непоточного MPM, такого как prefork:
Worker MPM использует несколько дочерних процессов. Он многопоточен в каждом дочернем процессе, и каждый поток обрабатывает одно соединение. Worker быстрый и высокомасштабируемый, а объем используемой памяти сравнительно низкий. Он хорошо подходит для многопроцессорных систем. С другой стороны, worker менее устойчив к неисправным модулям, и неисправные потоки могут повлиять на все потоки в дочернем процессе.
Prefork MPM использует несколько дочерних процессов, каждый из которых обрабатывает одно соединение за раз. Prefork хорошо подходит для одно- или двухпроцессорных систем, скорость сопоставима со скоростью worker, и он высоко устойчив к неисправным модулям и сбоям дочерних процессов. Но использование памяти высоко, больше трафика приводит к большему использованию памяти.
3 Параметры конфигурации времени выполнения
3.1 Поиск DNS:
Директива HostnameLookups включает поиск DNS, чтобы имена хостов могли быть записаны вместо IP-адреса. Это добавляет задержку к каждому запросу, поскольку поиск DNS должен быть завершен до завершения запроса. HostnameLookups по умолчанию отключен в Apache 1.3 и выше. Оставьте его отключенным и используйте программу постобработки, такую как logresolve, для разрешения IP-адресов в файлах журналов доступа Apache. Logresolve поставляется с Apache.
При использовании директив Allow from или Deny from используйте IP-адрес вместо доменного имени или имени хоста. В противном случае выполняется двойной поиск DNS, чтобы убедиться, что доменное имя или имя хоста не подделаны.
3.2 AllowOverride:
Если AllowOverride не установлен в ‘None’, то Apache попытается открыть файл .htaccess (как указано в директиве AccessFileName) в каждой директории, которую он посещает. Например:
DocumentRoot /var/www/html
Если запрос сделан для URI /index.html, то Apache попытается открыть /.htaccess, /var/.htaccess, /var/www/.htaccess и /var/www/html/.htaccess. Эти дополнительные обращения к файловой системе добавляют к задержке. Если .htaccess требуется для конкретной директории, то включите его только для этой директории.
3.3 FollowSymLinks и SymLinksIfOwnerMatch:
Если опция FollowSymLinks установлена, то сервер будет следовать символическим ссылкам в этой директории. Если установлено SymLinksIfOwnerMatch, то сервер будет следовать символическим ссылкам только в том случае, если целевой файл или директория принадлежат тому же пользователю, что и ссылка.
Если установлено SymLinksIfOwnerMatch, то Apache должен будет выполнять дополнительные системные вызовы, чтобы проверить, совпадает ли владение ссылки и целевого файла. Дополнительные системные вызовы также необходимы, когда FollowSymLinks НЕ установлен. Например:
DocumentRoot /vaw/www/html
Для запроса, сделанного для URI /index.html, Apache выполнит lstat() на /var, /var/www, /var/www/html и /var/www/html/index.html. Эти дополнительные системные вызовы добавят к задержке. Результаты lstat не кэшируются, поэтому они будут происходить при каждом запросе.
Для максимальной производительности установите FollowSymLinks везде и никогда не устанавливайте SymLinksIfOwnerMatch. Или, если SymLinksIfOwnerMatch требуется для директории, то установите его только для этой директории.
3.4 Согласование контента:
Избегайте согласования контента для быстрого ответа. Если согласование контента требуется для сайта, используйте файлы type-map вместо директивы Options MultiViews. С MultiViews Apache должен просканировать директорию на наличие файлов, что добавляет к задержке.
3.5 MaxClients:
MaxClients устанавливает лимит на максимальное количество одновременных запросов, которые может поддерживать сервер. Не должно быть больше этого количества дочерних процессов. Его не следует устанавливать слишком низко, чтобы новые соединения не ставились в очередь, что в конечном итоге приводит к тайм-ауту, и ресурсы сервера остаются неиспользованными. Установка этого значения слишком высоким приведет к тому, что сервер начнет использовать свопинг, и время ответа резко ухудшится. Подходящее значение для MaxClients можно рассчитать как: MaxClients = Общая ОЗУ, выделенная для веб-сервера / Максимальный размер дочернего процесса —- [
4 ] Размер дочернего процесса для обслуживания статического файла составляет около 2-3 М. Для динамического контента, такого как PHP, это может быть около 15 М. Столбец RSS в
"ps -ylC httpd --sort:rss"показывает не свопированное физическое использование памяти процессами Apache в килобайтах.
Если количество одновременных пользователей превышает MaxClients, запросы будут ставиться в очередь до числа, основанного на директиве ListenBacklog. Увеличьте ServerLimit, чтобы установить MaxClients выше 256.
3.6 MinSpareServers, MaxSpareServers и StartServers:
MaxSpareServers и MinSpareServers определяют, сколько дочерних процессов следует поддерживать в ожидании запросов. Если MinSpareServers слишком низкий и поступает множество запросов, то Apache должен будет создавать дополнительные дочерние процессы для обслуживания запросов. Создание дочерних процессов относительно дорого. Если сервер занят созданием дочерних процессов, он не сможет немедленно обслуживать запросы клиентов. MaxSpareServers не следует устанавливать слишком высоким, это может вызвать проблемы с ресурсами, так как дочерние процессы потребляют ресурсы.
Настройте MinSpareServers и MaxSpareServers так, чтобы Apache не приходилось часто создавать более 4 дочерних процессов в секунду (Apache может создать максимум 32 дочерних процесса в секунду). Когда создается более 4 детей в секунду, в ErrorLog будет записано сообщение.
Директива StartServers устанавливает количество дочерних серверных процессов, создаваемых при запуске. Apache продолжит создавать дочерние процессы, пока не будет достигнуто значение MinSpareServers. Это не оказывает значительного влияния на производительность, если сервер не перезапускается часто. Если запросов много и Apache перезапускается часто, установите это значение на относительно высокое значение.
3.7 MaxRequestsPerChild:
Директива MaxRequestsPerChild устанавливает лимит на количество запросов, которые будет обрабатывать отдельный дочерний серверный процесс. После MaxRequestsPerChild запросов дочерний процесс завершится. По умолчанию это значение установлено в 0, что означает, что дочерний процесс никогда не истечет. Подходящее значение — несколько тысяч. Это может помочь предотвратить утечку памяти, так как процесс умирает после обслуживания определенного количества запросов. Не устанавливайте это значение слишком низким, так как создание новых процессов имеет накладные расходы.
3.8 KeepAlive и KeepAliveTimeout:
Директива KeepAlive позволяет отправлять несколько запросов по одному и тому же TCP-соединению. Это особенно полезно при обслуживании HTML-страниц с множеством изображений. Если KeepAlive установлен в Off, то для каждого изображения должно быть установлено отдельное TCP-соединение. Накладные расходы из-за установления TCP-соединения можно устранить, включив KeepAlive.
KeepAliveTimeout определяет, как долго ждать следующего запроса. Установите это значение на низкое значение, возможно, от двух до пяти секунд. Если оно установлено слишком высоким, дочерние процессы будут заняты ожиданием клиента, когда их можно было бы использовать для обслуживания новых клиентов.
4 HTTP-сжатие и кэширование
HTTP-сжатие полностью специфицировано в HTTP/1.1. Сервер использует метод кодирования gzip или deflate для полезной нагрузки ответа перед отправкой его клиенту. Клиент затем распаковывает полезную нагрузку. Нет необходимости устанавливать какое-либо дополнительное программное обеспечение на стороне клиента, так как все основные браузеры это поддерживают. Использование сжатия сэкономит пропускную способность и улучшит время ответа, исследования показали средний прирост сжатия в 75.2 % [
5 ]. HTTP-сжатие можно включить в Apache с помощью модуля
mod_deflate
. Полезная нагрузка сжимается только в том случае, если браузер запрашивает сжатие, в противном случае предоставляется несжатый контент. Браузер, осведомленный о сжатии, информирует сервер о том, что он предпочитает сжатый контент через заголовок HTTP-запроса - “Accept-Encoding: gzip,deflate”. Затем сервер отвечает сжатой полезной нагрузкой, а заголовок ответа установлен на “
Content-Encoding:
gzipСледующий пример использует telnet для просмотра заголовков запроса и ответа:
bash-3.00$ telnet www.webperformance.org 80
Trying 24.60.234.27...
Connected to www.webperformance.org (24.60.234.27).
Escape character is '^]'.
HEAD / HTTP/1.1
Host: www.webperformance.org
Accept-Encoding: gzip,deflate
HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 02:29:22 GMT
Server: Apache/2.0
X-Powered-By: PHP/5.1.1
Cache-Control: max-age=0
Expires: Sat, 31 Dec 2005 02:29:22 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Content-Type: text/html; charset=ISO-8859-1
В кэшировании копия данных хранится на стороне клиента или в прокси-сервере, чтобы ее не нужно было часто извлекать с сервера. Это сэкономит пропускную способность, уменьшит нагрузку на сервер и снизит задержку. Управление кэшем осуществляется через HTTP-заголовки. В Apache это можно сделать с помощью модулей mod_expires и mod_headers. Также существует кэширование на стороне сервера, при котором часто запрашиваемый контент хранится в памяти, чтобы его можно было быстро обслуживать. Модуль mod_cache можно использовать для кэширования на стороне сервера, он стабилен в производственной среде в версии Apache 2.2.
5 Отдельный сервер для статического и динамического контента
Процессы Apache, обслуживающие динамический контент, занимают от 3 М до 20 М ОЗУ. Он растет, чтобы разместить контент, который он обслуживает, и никогда не уменьшается, пока процесс не завершится. Скажем, процесс Apache растет до 20 М, чтобы обслуживать динамический контент. После завершения запроса он свободен для обслуживания любого другого запроса. Если поступает запрос на изображение, то этот 20 М процесс обслуживает статический контент, который мог бы быть обслужен процессом в 1 М. Память используется неэффективно.
Используйте маленький Apache (с минимальным количеством статически скомпилированных модулей) в качестве фронтенд-сервера для обслуживания статического контента. Запросы на динамический контент перенаправляются на тяжелый Apache (скомпилированный со всеми необходимыми модулями). Использование легкого фронтенд-сервера имеет то преимущество, что статический контент обслуживается быстро без значительного использования памяти, и только динамический контент передается на тяжелый сервер.
Перенаправление запросов можно осуществить с помощью модулей mod_proxy и rewrite_module. Предположим, что есть легкий сервер Apache, слушающий на порту 80, и тяжелый Apache, слушающий на порту 8088. Тогда следующая конфигурация в легком Apache может быть использована для перенаправления всех запросов, кроме запросов на изображения, на тяжелый сервер.
ProxyPassReverse / http://%{HTTP_HOST}:8088/
RewriteEngine on ---- [9]
RewriteCond %{REQUEST_URI} !.*\.(gif|png|jpg)$
RewriteRule ^/(.*) http://%{HTTP_HOST}:8088/$1 [P]Все запросы, кроме изображений, проксируются на сервере бэкенда. Ответ принимается фронтенд-сервером и затем передается клиенту. Что касается клиента, все ответы, кажется, поступают с одного сервера.
6 Заключение
Настройка Apache для максимальной производительности — это сложная задача, нет жестких и быстрых правил. Поймите требования веб-сервера и экспериментируйте с различными доступными опциями. Используйте инструменты, такие как
ab
и
httperf
для измерения производительности веб-сервера. Легкие серверы, такие как
tux
,
thttpd
, также могут использоваться в качестве фронтенд-сервера. Если используется сервер базы данных, убедитесь, что он оптимизирован, чтобы не создавать узкие места. В случае MySQL
mtop
можно использовать для мониторинга медленных запросов. Производительность PHP-скриптов можно улучшить с помощью продукта кэширования PHP, такого как
Turck MMCache
. Он устраняет накладные расходы из-за компиляции, кэшируя PHP-скрипты в скомпилированном состоянии.
Библиография
1 http://news.netcraft.com/archives/web_server_survey.html
2 http://httpd.apache.org/docs/2.2/dso.html
3 http://httpd.apache.org/docs/2.2/mpm.html
4 http://modperlbook.org/html/ch11_01.html
5 http://www.speedupyoursite.com/18/18-2t.html
6 http://www.xs4all.nl/~thomas/apachecon/PerformanceTuning.html
7 http://www.onlamp.com/pub/a/onlamp/2004/02/05/lamp_tuning.html
8 http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
9 Linux Server Hacks by Rob Flickenger
Биография автора: Вишну Рам имеет степень магистра в области коммуникационных систем в IIT Madras. Он присоединился к Bobcares в 2003 году и с тех пор работает в Poornam.
Get new posts in your inbox
No spam. Unsubscribe anytime.