Не спасовать перед лавиной: Подготавливаем веб-сервер к высоким нагрузкам. Отключение разрешения имён хостов
Введение
По данным Netcraft, Apache — самый популярный веб-сервер в интернет, он
обслуживает множество серверов и сайтов. Часто возникает необходимость
увеличить производительность веб-сервера. Наверное лучший способ это
сделать — перейти к схеме frontend+backend, но это может потребовать
достаточно серьезных изменений в приложении (например, у вас наверняка
отвалятся всяческие индикаторы прогресса аплоада файлов).
Другой способ — просто увеличить производительность сервера — поставить
более быстрый процессор и больше памяти.
Однако и первое и второе требует много времени и ресурсов, так что на
первое время можно попробовать ускорить apache путем оптимизации его
конфигурации. Существуют оптимизации, которые можно применить только
при пересборке apache, другие же можно применять без перекомпиляции
сервера.
Загружайте только необходимые модули
Apache — модульная программа, бОльшая часть функций которой реализуется
в модулях. При этом эти модули могут быть как вкомпилированы, так и
собраны в виде DSO — динамических библиотеках. Большинство современных
дистрибутивов поставляет apache с набором DSO, так что не нужные модули
можно легко отключить без перекомпиляции.
Запускайте apache только с необходимыми модулями, чтобы уменьшить
потребление памяти. Если вы решили скомпилировать apache
самостоятельно, то либо тщательно подходите к выбору списка модулей,
которые вы включите, либо компилируйте их как DSO используя apxs в
apache1 и apxs2 в apache2. Для того чтобы отключить ненужные
DSO-модули, достаточно закомментировать лишние строчки LoadModule в
httpd.conf. Apache со статически скомпилированными модулями будет
потреблять чуть меньше памяти, однако вам придется каждый раз его
перекомпилировать для изменения списка модулей.
Выберете подходящий MPM
В apache каждый запрос обрабатывается в своем процессе или потоке. При
компиляции apache позволяет выбирать один из нескольким MPM
(Multi-processing module), которые отвечают за прослушивание портов,
прием запросов и раздачу этих запросов дочерним процессам или потокам,
в которых эти запросы будут обработаны.
Выбор MPM зависит от нескольких факторов, таких как наличие поддержки
потоков в ОС, количества свободной памяти, а также требований
стабильности и безопасности.
Если безопасность очень важна, следует выбрать peruser MPM, пожертвовав
производительностью.
Если важна именно производительность, то выбор ограничивается двумя
mpm: prefork и worker.
Worker — поточный MPM, т.е. в нем каждый запрос обслуживается в
отдельном потоке одного из дочерних процессов. Потоки — более легкие
для ОС объекты, чем процессы, они более эффективно используют память и
переключения контекста для них происходят быстрее. Однако, из-за того
что каждый поток имеет доступ ко всей памяти процесса, worker mpm более
подвержен сбоям: сбой одного потока может повлечь падение всего
процесса, в котором находился этот поток (именно поэтому worker mpm
запускает несколько дочерних процессов с несколькими потоками в
каждом).
Perfork — mpm использует несколько дочерних процессов, каждый дочерний
процесс обрабатывает одно подключение. Из-за того что процесс — более
тяжелая структура, он использует немного больше ресурсов, зато он менее
подвержен сбоям — обработка каждого отдельного запроса не зависит от
других процессов.
К сожалению, для смены mpm требуется перекомпиляция apache. Тут
проявляют свои достоинства source-based дистрибутивы: вы можете легко
перекомпилировать apache и все зависимые от него пакеты, не превратив
систему в свалку. Бинарные дистрибутивы выходят из этой ситуации
по-разному. Например в RHEL в apache rpm находится сразу две версии
apache — с worker и prefork mpm (prefork используется по умолчанию).
Однако worker mpm не поддерживает php. Так что если вы хотите php и
worker mpm вам придется компилировать его самостоятельно либо искать
сторонние репозитории.
DNS lookup
Директива HostnameLookups включает reverse DNS запросы, так что в логи
будут попадать dns-хосты клиентов вместо ip-адресов. Разумеется, что
это существенно замедляет обработку запроса, т.к. запрос не
обрабатывается пока не будет получит ответ от DNS-сервера. Поэтому
следите чтобы эта директива всегда была выключена (HostnameLookups
Off), а если вам все-таки нужны dns-адреса, вы можете узнать их позже,
прогнав лог в утилите logresolve (которая поставляется с apache).
Кроме того, следите чтобы в директивах Allow from и Deny From
использовались ip-адреса а не доменные имена. Иначе apache будет делать
два dns запроса (обратный и прямой) чтобы убедиться что клиент-тот за
кого себя выдает.
AllowOverride
Если директива AllowOverride не установлена в ‘None’, apache будет
пытаться открыть.htaccess файлы в каждой директории которую он
посещает и во всех директориях выше нее. Например:
DocumentRoot /var/www/html
AllowOverride all
Если будет запрошен /index.html, apache попытается открыть (и
интерпретировать) файлы /.htaccess, /var/.htaccess, /var/www/.htaccess,
и /var/www/html/.htaccess. Это увеличивает время обработки запроса. Так
что, если вам нужен.htaccess только для одной директории, разрешайте
его только для нее:
DocumentRoot /var/www/html
AllowOverride None
AllowOverride all
FollowSymLinks и SymLinksIfOwnerMatch
Если для директории включена опция FollowSymLinks, сервер будет
следовать по символическим ссылкам в этой директории. Если для
директории включена опция SymLinksIfOwnerMatch, apache будет следовать
по символическим ссылкам только если владелец файла или директории, на
которую указывает эта ссылка совпадает с владельцем указанной
директории. Так что при включенной опции SymLinksIfOwnerMatch apache
делает больше системных запросов.
Кроме того, дополнительные системные запросы требуются когда
FollowSymlinks НЕ УСТАНОВЛЕН. Т.о. наиболее оптимальная ситуация для
производительности — когда опция FollowSymlinks включена.
Content Negotiatio
Старайтесь избегать content negotiaion.
MaxClients
Директива MaxClients устанавливает максимальное количество параллельных
запросов, которые будет поддерживать сервер. Apache не будет порождать
больше процессов/потоков чем MaxClients. Значение MaxClient не долно
быть слишком маленьким (иначе много клиентов останутся необслуженными),
но и не стоит устанавливать слишком большое количество — лучше не
обслужить часть клиентов чем исчерпать все ресурсы, залезть в своп и
умереть под нагрузкой. Хорошим может быть значение MaxClients =
количество памяти выделенное под веб-сервер / максимальный размер
порожденного процесса или потока. Для статических файлов apache
использует около 2-3 Мб на процесс, для динамики (php, cgi) — зависит
от скрипта, но обычно около 16-32 Мб.
Вы можете прикинуть примерный размер посмотрев на колонку rss в выводе
`ps -ylC httpd —sort:rss`
Если сервер уже обслуживает MaxClients запросов, новые запросы попадут
в очередь, размер которой устанавливается с помощью директивы
ListenBacklog.
MinSpareServers, MaxSpareServers, и StartServers
Т.к. создание потока, и особенно процесса — дорогая операция, apache
создает их заранее. Директивы MaxSpareServers и MinSpareServers
устанавливают как много процессов/потоков должны ожидать в готовности
принять запрос (максимум и минимум). Если значение MinSpareServers
слишком маленькое и неожиданно приходит много запросов, apache вынужден
будет создавать много новых процессов/потоков, что создаст
дополнительную нагрузку в этой стрессовой ситуации. С другой стороны,
если MaxSpareServers слишком велико, apache будет сильно нагружать
систему этими процессами, даже если количество клиентов минимально.
Постарайтесь установить такие MinSpareServers и MaxSpareServers, чтобы
apache не создавал более 4 процессов/потоков в секунду. Если он создаст
более 4, в ErrorLog будет помещено сообщение об этом. Это — сигнал того
что MinSpareServers слишком мало.
MaxRequestsPerChild
Директива MaxRequestsPerChild устанавливает сколько запросов может
обработать один дочерний процесс/поток прежде чем он будет завершен. По
умолчанию значение этой директивы установлено в 0, что означает что
однажды созданный процесс/поток не будет завершен никогда (ну кроме
случаев остановки сервера или краха этого процесса/потока). Рекомендую
установить MaxRequestsPerChild равное какому-нибудь достаточно большому
числу (несколько тысяч). Это не создаст излишней нагрузки, связаной с
тем что apache будет вынужден создавать новые дочерние процессы, в то
же время это поможет избавиться от проблем с утечкой памяти в дочерних
процессах (что очень возможно например если вы используете нестабильную
версию php).
KeepAlive и KeepAliveTimeout
KeepAlive позволяет делать несколько запросов в одном TCP-подключении.
Это особенно полезно для html-страниц с большим количеством
изображений. Если KeepAlive установлен в Off, то для самой страницы и
для каждого изображения будет создано отдельное подключение (которое
нужно будет обработать master-процессу), что плохо и для сервера и для
клиента. Так что для подобных случаев рекомендуется устанавливать
KeepAlive в On. Для других применений (например для download-сервера)
KeepAlive может быть бесполезен и даже вреден, т.к. при включенном
KeepAlive сервер закрывает соединение не сразу, а ждет KeepAliveTimeout
секунд нового запроса. Для того чтобы процессы не висели слишком долго
в бесполезном ожидании, устанавливайте KeepAliveTimeout достаточно
малым, около 5-10 секунд обычно достаточно.
Сжатие
HTTP-сжатие было определено в стандарте HTTP/1.1, и сейчас все
современные клиентские программы и практически все сервера его
поддерживают. Сервер может отдавать ответ в gzip или deflate, а
клиентская программа незаметно для пользователя разжимает данные. Это
уменьшает количество передаваемого трафика (до 75%), но конечно же
повышает использование процессора.
Однако если ваш сервер посещает много клиентов с медленным подключение,
сжатие может снизить нагрузку с вашего сервера из-за того что сервер
сможет быстрее передать сжатый ответ и освободить ресурсы, занятые
дочерним процессом. Особенно сильно этот эффект может быть заметен если
у вас быстрый процессор, но мало памяти.
Кеширование конфигурируется директивами модуля mod_deflate. Имейте в
виду, что не следует устанавливать степень сжатия gzip более 4-5 — это
потребует существенно большего времени CPU, а эффект будет достаточно
невелик. Ну и разумеется не нужно пытаться сжать изображения в jpg, gif
и png, музыку, видео файлы и все другие бинарные файлы, которые уже и
так хорошо сжаты.
Кеширование на стороне клиента
Не забывайте устанавливать Expires заголовки на статические файлы (см.
модуль mod_expires). Если файл не изменяется, то его всегда следует
попробовать закешировать на клиенте. Тогда у клиента будут быстрее
загружаться страницы, а сервер освободится от лишних запросов.
Apache — популярный веб-сервер в интернет, он обслуживает множество серверов и сайтов. Часто возникает необходимость увеличить производительность веб-сервера. Наверное лучший способ это сделать — перейти к схеме frontend+backend, но это может потребовать достаточно серьезных изменений в приложении (например, у вас наверняка отвалятся всяческие индикаторы прогресса аплоада файлов:).
Другой способ — просто увеличить производительность сервера — поставить более быстрый процессор и больше памяти.
Однако и первое и второе требует много времени и ресурсов, так что на первое время можно попробовать ускорить apache путем оптимизации его конфигурации. Существуют оптимизации, которые можно применить только при пересборке apache, другие же можно применять без перекомпиляции сервера.
Загружайте только необходимые модули
Apache — модульная программа, большая часть функций которой реализуется в модулях. При этом эти модули могут быть как вкомпилированы, так и собраны в виде DSO — динамических библиотеках. Большинство современных дистрибутивов поставляет apache с набором DSO, так что не нужные модули можно легко отключить без перекомпиляции.
Запускайте apache только с необходимыми модулями, чтобы уменьшить потребление памяти. Если вы решили скомпилировать apache самостоятельно, то либо тщательно подходите к выбору списка модулей, которые вы включите, либо компилируйте их как DSO используя apxs в apache1 и apxs2 в apache2. Для того чтобы отключить ненужные DSO-модули, достаточно закомментировать лишние строчки LoadModule в httpd.conf. Apache со статически скомпилированными модулями будет потреблять чуть меньше памяти, однако вам придется каждый раз его перекомпилировать для изменения списка модулей.
Выберете подходящий MPM
В apache каждый запрос обрабатывается в своем процессе или потоке. При компиляции apache позволяет выбирать один из нескольким MPM (Multi-processing module), которые отвечают за прослушивание портов, прием запросов и раздачу этих запросов дочерним процессам или потокам, в которых эти запросы будут обработаны.
Выбор MPM зависит от нескольких факторов, таких как наличие поддержки потоков в ОС, количества свободной памяти, а также требований стабильности и безопасности.
Если безопасность очень важна, следует выбрать peruser MPM, пожертвовав производительностью.
Если важна именно производительность, то выбор ограничивается двумя mpm: prefork и worker.
Worker
- поточный MPM, т.е. в нем каждый запрос обслуживается в отдельном потоке одного из дочерних процессов. Потоки — более легкие для ОС объекты, чем процессы, они более эффективно используют память и переключения контекста для них происходят быстрее. Однако, из-за того что каждый поток имеет доступ ко всей памяти процесса, worker mpm более подвержен сбоям: сбой одного потока может повлечь падение всего процесса, в котором находился этот поток (именно поэтому worker mpm запускает несколько дочерних процессов с несколькими потоками в каждом).
Perfork
- mpm использует несколько дочерних процессов, каждый дочерний процесс обрабатывает одно подключение. Из-за того что процесс — более тяжелая структура, он использует немного больше ресурсов, зато он менее подвержен сбоям — обработка каждого отдельного запроса не зависит от других процессов.
К сожалению, для смены mpm требуется перекомпиляция apache. Тут проявляют свои достоинства source-based дистрибутивы: вы можете легко перекомпилировать apache и все зависимые от него пакеты, не превратив систему в свалку. Бинарные дистрибутивы выходят из этой ситуации по-разному. Например в RHEL в apache rpm находится сразу две версии apache — с worker и prefork mpm (prefork используется по умолчанию). Однако worker mpm не поддерживает php. Так что если вы хотите php и worker mpm вам придется компилировать его самостоятельно либо искать сторонние репозитории.
DNS lookup
Директива HostnameLookups включает reverse DNS запросы, так что в логи будут попадать dns-хосты клиентов вместо ip-адресов. Разумеется, что это существенно замедляет обработку запроса, т.к. запрос не обрабатывается пока не будет получит ответ от DNS-сервера. Поэтому следите чтобы эта директива всегда была выключена (HostnameLookups Off), а если вам все-таки нужны dns-адреса, вы можете узнать их позже, прогнав лог в утилите logresolve (которая поставляется с apache).
Кроме того, следите чтобы в директивах Allow from и Deny From использовались ip-адреса а не доменные имена. Иначе apache будет делать два dns запроса (обратный и прямой) чтобы убедиться что клиент-тот за кого себя выдает.
AllowOverride
Если директива AllowOverride не установлена в ‘None’, apache будет пытаться открыть.htaccess файлы в каждой директории которую он посещает и во всех директориях выше нее. Например:
DocumentRoot /var/www/html
Если будет запрошен /index.html, apache попытается открыть (и интерпретировать) файлы /.htaccess, /var/.htaccess, /var/www/.htaccess, и /var/www/html/.htaccess. Это увеличивает время обработки запроса. Так что, если вам нужен.htaccess только для одной директории, разрешайте его только для нее:
DocumentRoot /var/www/html
FollowSymLinks и SymLinksIfOwnerMatch
Если для директории включена опция FollowSymLinks, сервер будет следовать по символическим ссылкам в этой директории. Если для директории включена опция SymLinksIfOwnerMatch, apache будет следовать по символическим ссылкам только если владелец файла или директории, на которую указывает эта ссылка совпадает с владельцем указанной директории. Так что при включенной опции SymLinksIfOwnerMatch apache делает больше системных запросов.
Кроме того, дополнительные системные запросы требуются когда FollowSymlinks НЕ УСТАНОВЛЕН. Т.о. наиболее оптимальная ситуация для производительности — когда опция FollowSymlinks включена.
Content Negotiatio
Старайтесь избегать content negotiaion.
MaxClients
Директива MaxClients устанавливает максимальное количество параллельных запросов, которые будет поддерживать сервер. Apache не будет порождать больше процессов/потоков чем MaxClients. Значение MaxClient не долно быть слишком маленьким (иначе много клиентов останутся необслуженными), но и не стоит устанавливать слишком большое количество — лучше не обслужить часть клиентов чем исчерпать все ресурсы, залезть в своп и умереть под нагрузкой. Хорошим может быть значение MaxClients = количество памяти выделенное под веб-сервер / максимальный размер порожденного процесса или потока. Для статических файлов apache использует около 2-3 Мб на процесс, для динамики (php, cgi) — зависит от скрипта, но обычно около 16-32 Мб.
Если сервер уже обслуживает MaxClients запросов, новые запросы попадут в очередь, размер которой устанавливается с помощью директивы ListenBacklog.
MinSpareServers, MaxSpareServers, и StartServers
Т.к. создание потока, и особенно процесса — дорогая операция, apache создает их заранее. Директивы MaxSpareServers и MinSpareServers устанавливают как много процессов/потоков должны ожидать в готовности принять запрос (максимум и минимум). Если значение MinSpareServers слишком маленькое и неожиданно приходит много запросов, apache вынужден будет создавать много новых процессов/потоков, что создаст дополнительную нагрузку в этой стрессовой ситуации. С другой стороны, если MaxSpareServers слишком велико, apache будет сильно нагружать систему этими процессами, даже если количество клиентов минимально.
Постарайтесь установить такие MinSpareServers и MaxSpareServers, чтобы apache не создавал более 4 процессов/потоков в секунду. Если он создаст более 4, в ErrorLog будет помещено сообщение об этом. Это — сигнал того что MinSpareServers слишком мало.
MaxRequestsPerChild
Директива MaxRequestsPerChild устанавливает сколько запросов может обработать один дочерний процесс/поток прежде чем он будет завершен. По умолчанию значение этой директивы установлено в 0, что означает что однажды созданный процесс/поток не будет завершен никогда (ну кроме случаев остановки сервера или краха этого процесса/потока). Рекомендую установить MaxRequestsPerChild равное какому-нибудь достаточно большому числу (несколько тысяч). Это не создаст излишней нагрузки, связаной с тем что apache будет вынужден создавать новые дочерние процессы, в то же время это поможет избавиться от проблем с утечкой памяти в дочерних процессах (что очень возможно например если вы используете нестабильную версию php).
KeepAlive и KeepAliveTimeout
KeepAlive позволяет делать несколько запросов в одном TCP-подключении. Это особенно полезно для html-страниц с большим количеством изображений. Если KeepAlive установлен в Off, то для самой страницы и для каждого изображения будет создано отдельное подключение (которое нужно будет обработать master-процессу), что плохо и для сервера и для клиента. Так что для подобных случаев рекомендуется устанавливать KeepAlive в On. Для других применений (например для download-сервера) KeepAlive может быть бесполезен и даже вреден, т.к. при включенном KeepAlive сервер закрывает соединение не сразу, а ждет KeepAliveTimeout секунд нового запроса. Для того чтобы процессы не висели слишком долго в бесполезном ожидании, устанавливайте KeepAliveTimeout достаточно малым, около 5-10 секунд обычно достаточно.
Сжатие
HTTP-сжатие было определено в стандарте HTTP/1.1, и сейчас все современные клиентские программы и практически все сервера его поддерживают. Сервер может отдавать ответ в gzip или deflate, а клиентская программа незаметно для пользователя разжимает данные. Это уменьшает количество передаваемого трафика (до 75%), но конечно же повышает использование процессора.
Однако если ваш сервер посещает много клиентов с медленным подключение, сжатие может снизить нагрузку с вашего сервера из-за того что сервер сможет быстрее передать сжатый ответ и освободить ресурсы, занятые дочерним процессом. Особенно сильно этот эффект может быть заметен если у вас быстрый процессор, но мало памяти.
Кеширование конфигурируется директивами модуля mod_deflate. Имейте в виду, что не следует устанавливать степень сжатия gzip более 4-5 — это потребует существенно большего времени CPU, а эффект будет достаточно невелик. Ну и разумеется не нужно пытаться сжать изображения в jpg, gif и png, музыку, видео файлы и все другие бинарные файлы, которые уже и так хорошо сжаты.
Вообще, если вы можете не поднимать Apache , не делайте этого. Задумайтесь, может ли нужные вам задачи выполнять lighttpd или thttpd . Эти веб-серверы могут оказаться весьма кстати в ситуациях, где системных ресурсов на всех не хватает, а работать должно. Ещё раз повторюсь: речь идёт о тех ситуациях, когда функциональности этих продуктов будет достаточно для выполнения поставленных задач (кстати, lighttpd умеет работать с PHP ). В тех ситуациях, где без Apache ну просто никак не обойтись, всё равно обычно можно освободить немало системных ресурсов, перенаправив запросы к статическому контенту (JavaScript, графика) от Apache к легковесному HTTP-серверу. Наибольшей проблемой Apache является его большой аппетит к оперативной памяти. В этой статье я рассмотрю методы, помогающие ускорить работу и снизить объёмы занимаемой им памяти:
Загрузка меньшего количества модулей
Первым делом необходимо избавиться загрузки от ненужных модулей. Просмотрите конфиг-файлы и определите, какие модули у вас загружаются. Все ли загружаемые модули вам нужны? Найдите то, что не используется и отключите нафиг, этим вы сэкономите какое-то количество памяти.
Обработка меньшего числа параллельных запросов
Чем большему количеству процессов Apache разрешено запускаться одновременно, тем больше одновременных запросов он сможет обработать. Увеличивая это число, вы тем самым увеличиваете и объём памяти, отдаваемой под Apache . Воспользовавшись top, можно увидеть, что каждый процесс Apache занимает совсем немножко памяти, поскольку используются разделяемые библиотеки. В Debian 5 с Apache 2 по умолчанию используется такая конфигурация:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 20 MaxRequestsPerChild 0
Директива StartServers определяет количество процессов сервера, запускаемых изначально, сразу после его старта. Директивы MinSpareServers и MaxSpareServers определяют минимальное и максимальное количество дочерних «запасных» процессов Apache . Такие процессы находятся в состоянии ожидания входящих запросов и не выгружаются, что даёт возможность ускорить реакцию сервера на новые запросы. Директива MaxClients определяет максимальное количество параллельных запросов, одновременно обрабатываемых сервером. Когда количество одновременных соединений превысит это количество, новые соединения будут поставлены в очередь на обработку. Фактически, директива MaxClients и определяет максимально-допустимое число дочерних процессов Apache ,запущенных одновременно. Директива MaxRequestsPerChild определяет количество запросов, которое должен обработать дочерний процесс Apache , прежде чем завершить своё существование. Если значение этой директивы установлено равным нулю, то процесс не будет «истекать».
Для своего домашнего сервера, с соответствующими нуждами, я исправил конфигурацию на следующую:
StartServers 1 MinSpareServers 1 MaxSpareServers 1 MaxClients 5 MaxRequestsPerChild 300
Конечно же, приведённая выше конфигурация совершенно не годится для использования на высокозагруженных серверах, но для дома, на мой взгляд — самое оно.
Циркуляция процессов
Как можно было заметить, я изменил значение директивы MaxRequestsPerChild . Ограничив таким образом время жизни дочерних процессов количеством обработанных запросов, можно избежать случайных утечек памяти, вызванных криво-написанными скриптами.
Использование не слишком «долгих» KeepAlive
KeepAlive — это метод поддержки постоянного соединения между клиентом и сервером. Изначально протокол HTTP разрабатывался как не ориентированный на постоянные соединения. То есть, когда веб-страница отправляется клиенту, все её части (картинки, фреймы, JavaScript) передаются с использованием различных, отдельно устанавливаемых соединений. С появлением KeepAlive , у браузеров появилась возможность запрашивать постоянное соединение и, установив его, загружать данные, используя одно установленное соединение. Такой способ даёт неслабый прирост производительности. Однако Apache по умолчанию использует слишком большой таймаут перед закрытием соединения, равный 15-ти секундам. Это значит, что после того, как был отдан весь контент клиенту, запросившему KeepAlive , дочерний процесс ещё 15 секунд будет находиться в ожидании входящих запросов. Многовато, однако. Лучше уменьшить этот таймаут до 2-3 секунд.
KeepAliveTimeout 2
Уменьшение таймаута
Как вариант, можно уменьшить значение директивы TimeOut , которая определяет время ожидания завершения отдельных запросов. По умолчанию её значение равно 300 , быть может, в вашем случае будет иметь смысл это значение уменьшить/увеличить. Я лично пока оставил как есть.
Уменьшение интенсивности логирования
На пути к увеличению производительности сервера можно попробовать снизить интенсивность ведения протоколов. Модули, такие как mod_rewrite , могут писать в лог отладочную информацию, и если она вам не нужна — отключайте её вывод.
Отключение разрешения имён хостов
На мой взгляд, нет никакой необходимости в том, чтобы выполнять обратное преобразование IP-адресов в имена хостов. Если они уж так сильно вам необходимы при анализе логов, то можно определять их на стадии анализа, а не в процессе работы сервера. За разрешение имён хостов отвечает директива HostnameLookups , которая, вообще-то, по умолчанию и установлена в Off , однако проверьте это, если действительно считаете необходимым отключить преобразование.
HostnameLookups Off
Отключение использования.htaccess
Обработка файлов .htaccess выполняется Apache каждый раз при запросе данных. Мало того, что Apache должен загрузить этот файл, так ещё немало времени и ресурсов уходит на его обработку. Взгляните на ваш веб-сервер и пересмотрите необходимость в использовании файлов .htaccess . Если вам нужны различные настройки для разных каталогов, может быть реально будет их вынести в основной файл конфигурации сервера? А отключить обработку .htaccess можно директивой в конфигурации сервера.
|Apache – очень производительный веб-сервер. Чтобы упростить начальную настройку, он предлагает большое количество предварительно установленных модулей. Потому Apache отлично подходит для развертывания новых проектов – с его помощью можно быстро настроить надежную среду производства. Однако по мере роста сайта (и, соответственно, объема трафика) вы можете столкнуться с проблемами.
Это руководство поможет увеличить производительность Apache на вашем виртуальном сервере.
1: Отключите ненужные модули
В Ubuntu и Debian-подобных системах есть каталоги etc/apache2/mods-enabled и /etc/apache2/mods-available/. В последнем хранится список всех модулей, установленных на данном сервере. А в каталоге mods-enabled находятся модули, включенные в данный момент.
Ситуация по умолчанию может отличаться на каждом сервере. Предположим, что на сервере по умолчанию включено 17 модулей. Как правило, этого слишком много для среднестатистического приложения. Кроме того, довольно сложно сразу определить ненужные модули, которые можно отключить, так как отдельные модули являются зависимостями других.
Для начала рекомендуется сохранить список модулей, активных по умолчанию, чтобы в дальнейшем иметь возможность использовать его для восстановления стандартных параметров. Затем вы можете просто отключить все ненужные модули по одному, перезапуская Apache после отключения каждого модуля, чтобы убедиться, что в системе не возникло ошибок.
В Ubuntu и Debian модули отключаются с помощью этой команды:
sudo a2dismod autoindex
Отдельные модули потребляют очень много ресурсов; если вы не используете следующие модули, просто отключите их:
- Rewrite
- Python
- Rack / Ruby / Passenger
Не все эти модули включены по умолчанию, однако ситуация индивидуальна для каждого сервера.
Примечание: Обычно Apache по умолчанию включает модуль rewrite, хотя его можно заменить модулем alias. Если вашему приложению подходит alias, отключите rewrite – это один из самых тяжелых модулей. Чтобы перейти с rewrite на alias, обратитесь к документации модуля . Даже если вы не сможете полностью отключить rewrite, вы сможете оптимизировать отдельные правила модуля.
Отключив модуль, перезапустите Apache, а затем проверьте лог ошибок, чтобы убедиться, что отключение модуля не навредило работе веб-сервера.
К примеру, вы можете получить такую ошибку:
Syntax error on line 6 of /etc/apache2/sites-enabled/site1:
Invalid command "DAVLockDB", perhaps misspelled or defined by a module not included in the server configuration
Action "configtest" failed.
Это значит, что отключенный модуль необходим для корректной работы веб-сервера. Включите его.
sudo a2enmod dav_fs
2: Переместите код
На сайтах PHP часто используется популярный модуль mod_php, а на сайтах ruby – Passenger Phusion (модули mod_rails или mod_rack).
Проблема в том, что код С для интерпретатора этого языка вложен в Apache, а это требует больше памяти для просмотра каждой страницы. Если популярная страница вашего сайта получает 30 HTTP-запросов, один из них будет для динамической страницы, а остальные 29 – для статических ресурсов (изображений, css и javascript). Чтобы увеличить производительность Apache, можно исключить 29 запросов, которые не обслуживают динамический контент.
Включение модуля mod_php может привести к тому, что на обслуживание одного дочернего процесса Apache будет требоваться 100 Мб RAM. Чем больше процессов Apache будет запущено на сервере, тем сложнее их будет обрабатывать.
Чтобы устранить эту проблему, можно использовать такие инструменты:
- Для PHP можно установить php-fpm, который является отдельным процессом на основе протокола fastcgi.
- В Python используйте uWSGI или gnunicorn
- Для Rails используйте Unicorn .
Сначала запускается процесс для PHP, Python или Ruby, а затем Apache перенаправляет вызовы динамического контента на этот процесс вместо того, чтобы пытаться обработать его с помощью вложенного кода.
После удаления модуля mod_php размер процессов Apache может измениться с 90-120 Мб до всего 10 Мб. Весь динамический контент обслуживается всего двумя процессами на бэкэнде.
3: Ограничьте количество процессов Apache
Многие операционные системы используют конфигурации по умолчанию, которые не очень подходят маленьким серверам – 25 дочерних процессов. Если каждый дочерний процесс Apache требует 120 Мб RAM, то сервер будет тратить 3 Гб только на Apache.
Веб-браузер одного пользователя может запрашивать 4 элемента сайта за раз, а значит всего 7-8 человек способны перенагрузить сервер. Веб-страницы зависают или грузятся очень медленно.
Сервер часто поддерживает такие мертвые процессы Apache в активном состоянии, пытаясь обслужить запрашиваемый контент, а это снижает количество доступных процессов для обслуживания пользователей и объем памяти. В результате вы получаете плохой пользовательский опыт.
Определите, сколько RAM требуется вашему приложению и сколько памяти остается, а затем выделите большую часть оставшейся памяти для Apache.
К примеру, у вас есть три процесса php-fpm для обработки динамического контента, где каждый процесс использует до 70 Мб памяти, а также сервер MySQL, который берет до 120 Мб RAM. В результате получается, что приложение использует 330 Мб памяти. Если у вас маленький сервер, вы можете выделить для Apache около 150 Мб памяти.
Когда веб-сервер Apache запущен, запустите команду 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
Найдите значение в столбце RES для Apache (например, 9 644) и запишите его. На данный момент веб-сервер использует почти 10 Мб памяти. Если ограничить количество дочерних процессов Apache до 15, 150 Мб выделенной памяти будет вполне достаточно.
Отредактируйте конфигурационный файл Apache (в Ubuntu и Debian это /etc/apache2/apache2.confand) и найдите раздел mpm_prefork_module. Найдите строку MaxClients и введите 15, а затем сохраните файл и перезапустите веб-сервер.
StartServers 3
MinSpareServers 3
MaxSpareServers 5
MaxClients 30
MaxRequestsPerChild 0
По умолчанию значение MaxClients может быть очень большим. Его нужно уменьшить.
Когда количество клиентов достигает предела, новые клиенты получат ошибку. Перезагрузив страницу, они смогут получить доступ к сайту.
Это звучит плохо, но все же лучше быстро закрыть эти соединения и сохранить нормальную работу сервера, чем ждать, пока сервер перестанет виснуть.
В некоторых ситуациях меньшее количество дочерних процессов помогает увеличить производительность сервера.
Часто в конфигурациях Apache используется предварительная настройка prefork mpm, которая считается безопасной и подходящей для PHP и других языков.
Если вы избавитесь от внешних модулей (PHP или Rails), вы можете рассмотреть worker MPM в качестве альтернативы.
Чтобы включить этот модуль, введите:
sudo apt-get install apache2-mpm-worker
The following packages will be REMOVED:
apache2-mpm-prefork libapache2-mod-php5
The following NEW packages will be installed:
apache2-mpm-worker
0 upgraded, 1 newly installed, 2 to remove and 2 not upgraded.
Need to get 2,284 B of archives.
After this operation, 8,718 kB disk space will be freed.
Do you want to continue ?
Внимание! В Ubuntu при установке модуля worker удаляется prefork mpm, mod_php и другие несовместимые модули.
Tags:Если вы решили увеличить производительность Apache (а на сегодняшний день это – один из самых популярных веб-серверов Сети), то вам пригодятся те советы, которые мы собираемся дать в этой статье.
1. Работайте только с действительно нужными вам модулями, а все остальное, сразу же и не задумываясь, удаляйте! Дело в том, что в этом случае вы сразу же уменьшите потребления памяти, что и повлечет за собой увеличение скорости. Второй вариант – скомпилировать модули как DSO, при помощи apxs (в apache 1) и apxs 2 в (apache 2), что сократить скорость работы примерно на 11-15%.
2. Правильно выберите MPM (Multi-processing module). Так как главная задача MPM – прослушивать порты, соответствующие установленным требованиям по безопасности, количеству свободной памяти или наличии поддержки потоков в ОС, то следует ограничить выбор на двух MPM – worker и prefork.
Worker – переносит обслуживание запросов в отдельный поток.
Perfork - работаете с несколькими дочерними процессами, каждый из которых отвечает за обработку одного подключения.
Чтобы сменить MPM, вы должны будете перекомпилировать apache при помощи source-based, что сразу же улучшит скорость работы всей системы.
3. Настройка DNS запросов. Во-первых, включите директиву «HostnameLookups» . Во-вторых, сделайте так, чтобы Allow from и Deny From директивах использовались не доменные имена, а IP-адреса, чтобы избавить apache от двойных запросов, которые он будет делать для того, чтобы проверять достоверность данных клиента.
4. Установить AllowOverride директиву в режим «None», иначе apache будет открывать (или пытаться сделать это) все htaccess-файлы в каждой посещаемой директории, а так же файлы выше ее:
Потому если вам нужен.htaccess только какой-нибудь одной директории, то поступите так:
Так же нужно отметит, что при включении для директории:
FollowSymLinks - сервер всегда будет следовать по символическим ссылкам в данной директории;
SymLinksIfOwnerMatch – сервер будет отслеживать ссылки только в случае если данные владельца директории совпадают с данными владельца директории, на которую указывает ссылка.
5. Так же откажитесь от Content Negotiatio.
6. Правильно задайте параметры MaxClients, определяющий количество одновременно обрабатываемых запросов. Найдите для себя оптимальное значение MaxClients, чтобы обслуживать оптимальное число клиентов. При этом следует помнить, что для статических файлов apache требуется 2-3 Мб на процесс, для динамики - 16-32 Мб.
7. Установка MinSpareServers, MaxSpareServers, и StartServers – а она должна привести к тому, чтобы apache отказался от создания 4-х потоков/процессов в 1-у секунду, что позволит не перегружать систему даже при максимальном числе клиентов.
8. Измените значение MaxRequestsPerChild при определении того, сколько запросов должен обработать 1 дочерний поток/процесс до своего завершения. Помните, что это значение (по умолчанию) выставлено как «ноль», потому лучше изменить его на 1000 и больше, что избавит вас от утечки памяти в дочерние процессы, что имеет огромное значение при использовании нестабильной версию PHP.
9. Активируйте KeepAlive и KeepAliveTimeout, которые в отключенном режиме создают отдельный поток для каждого размещенного на html-странице изображения, и «тормозит» страницы с большим числом изображений большого размера. В случаях с download-серверами KeepAlive лучше отключить, что сразу же избавит вас от долго ожидания перед закрытием сервером соединений.
10. Используйте сжатие, что позволит вам уменьшить количество передаваемого трафика на 75 процентов. И делайте это без всякой опаски, так как на сегодня все новейшие клиентские программы и сервера поддерживают HTTP-сжатие в стандарте HTTP/1.1. А постарастья сжать следует видео, музыку, и все jpg, gif png файлы.
Следует отметить, что параметры кэширование задаются директивами модуля mod_deflate. При этом не стоит устанавливать степень сжатия gzip более 4 или 5, так как это увеличит время CPU, и снизит общий эффект.
11. И конечно же не забывайте устанавливать на статических файлах (для этого применяется модуль mod_expires) Expires заголовки. Или закэшируйте его на клиенте в том случае, если файл не изменяется, что освободит сервер от лишних запросов, а клиент получит более быстро загружаемую страницу.
На новых VPS часто появляются проблемы с производительность работы Apache. Дело в том, что конфигурационные файлы которые создаются после установки Apache далеко не оптимизированы.
Симптомы плохой настройки могут быть работа VPS с обжорством RAM на 100% или CPU на 100%. После выполнения команды top или htop (если не работает выполните apt-get install htop) на первых строках будет процесс apache.
Я покажу оптимальный конфиг. файл для VPS
Оперативная память : 512 MB
Процессор : 2267 MHz
ОС : Debian 5
#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300
#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On
#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100
#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 15
##
## Server-Pool Size Regulation (MPM specific)
##
# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
В этом файле настроек можно поменять следующие параметры:
- MaxClients – ограничение максимального числа
- StartServers -устанавливает число дочерних процессов при запуске сервера.
- MinSpareServers – минимальное число неиспользуемых дочерних процессов.
- MaxSpareServers - соответственно максимальное число неиспользуемых дочерних процессов.
- MaxRequestsPerChild – максимальное количество запросов, которое разрешено обрабатывать дочернему процессу до переполнения. Нужен данный параметр, чтобы избежать утечку памяти или других ресурсов Apache, так как при переполнении дочерний процесс будет
одновременно запущенных процессов httpd. т.е. по сути установка лимита
на сжирание памяти самым “голодным” процессом httpd
принудительно завершен. В большенстве случаев изменение не требуется. Значение 0 – озхначает отсутствие ограничений.