Немного об Apache и производительности






Вообще, если вы можете не поднимать Apache, не делайте этого. Задумайтесь, может ли нужные вам задачи выполнять lighttpd или thttpd. Эти веб-серверы могут оказаться весьма кстати в ситуациях, где системных ресурсов на всех не хватает, а работать должно. Ещё раз повторюсь: речь идёт о тех ситуациях, когда функциональности этих продуктов будет достаточно для выполнения поставленных задач (кстати, lighttpd умеет работать с PHP). В тех ситуациях, где без Apache ну просто никак не обойтись, всё равно обычно можно освободить немало системных ресурсов, перенаправив запросы к статическому контенту (JavaScript, графика) от Apache к легковесному HTTP-серверу. Наибольшей проблемой Apache является его большой аппетит к оперативной памяти. В этой статье я рассмотрю методы, помогающие ускорить работу и снизить объёмы занимаемой им памяти:

  • загрузка меньшего количества модулей;
  • обработке меньшего числа параллельных запросов;
  • циркуляция процессов;
  • использование не слишком «долгих» KeepAlive;
  • уменьшение таймаута;
  • уменьшение интенсивности логирования;
  • отключение разрешения имён хостов;
  • отключение использования .htaccess.

Загрузка меньшего количества модулей

Первым делом необходимо избавиться загрузки от ненужных модулей. Просмотрите конфиг-файлы и определите, какие модули у вас загружаются. Все ли загружаемые модули вам нужны? Найдите то, что не используется и отключите нафиг, этим вы сэкономите какое-то количество памяти.

Обработка меньшего числа параллельных запросов

Чем большему количеству процессов Apache разрешено запускаться одновременно, тем больше одновременных запросов он сможет обработать. Увеличивая это число, вы тем самым увеличиваете и объём памяти, отдаваемой под Apache. Воспользовавшись top, можно увидеть, что каждый процесс Apache занимает совсем немножко памяти, поскольку используются разделяемые библиотеки. В Debian 5 с Apache 2 по умолчанию используется такая конфигурация:

Директива StartServers определяет количество процессов сервера, запускаемых изначально, сразу после его старта. Директивы MinSpareServers и MaxSpareServers определяют минимальное и максимальное количество дочерних «запасных» процессов Apache. Такие процессы находятся в состоянии ожидания входящих запросов и не выгружаются, что даёт возможность ускорить реакцию сервера на новые запросы. Директива MaxClients определяет максимальное количество параллельных запросов, одновременно обрабатываемых сервером. Когда количество одновременных соединений превысит это количество, новые соединения будут поставлены в очередь на обработку. Фактически, директива MaxClients и определяет максимально-допустимое число дочерних процессов Apache,запущенных одновременно. Директива MaxRequestsPerChild определяет количество запросов, которое должен обработать дочерний процесс Apache, прежде чем завершить своё существование. Если значение этой директивы установлено равным нулю, то процесс не будет «истекать».

Для своего домашнего сервера, с соответствующими нуждами, я исправил конфигурацию на следующую:

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

Циркуляция процессов

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

Использование не слишком «долгих» KeepAlive

KeepAlive — это метод поддержки постоянного соединения между клиентом и сервером. Изначально протокол HTTP разрабатывался как не ориентированный на постоянные соединения. То есть, когда веб-страница отправляется клиенту, все её части (картинки, фреймы, JavaScript) передаются с использованием различных, отдельно устанавливаемых соединений. С появлением KeepAlive, у браузеров появилась возможность запрашивать постоянное соединение и, установив его, загружать данные, используя одно установленное соединение. Такой способ даёт неслабый прирост производительности. Однако Apache по умолчанию использует слишком большой таймаут перед закрытием соединения, равный 15-ти секундам. Это значит, что после того, как был отдан весь контент клиенту, запросившему KeepAlive, дочерний процесс ещё 15 секунд будет находиться в ожидании входящих запросов. Многовато, однако. Лучше уменьшить этот таймаут до 2-3 секунд.

Уменьшение таймаута

Как вариант, можно уменьшить значение директивы TimeOut, которая определяет время ожидания завершения отдельных запросов. По умолчанию её значение равно 300, быть может, в вашем случае будет иметь смысл это значение уменьшить/увеличить. Я лично пока оставил как есть.

Уменьшение интенсивности логирования

На пути к увеличению производительности сервера можно попробовать снизить интенсивность ведения протоколов. Модули, такие как mod_rewrite, могут писать в лог отладочную информацию, и если она вам не нужна — отключайте её вывод.

Отключение разрешения имён хостов

На мой взгляд, нет никакой необходимости в том, чтобы выполнять обратное преобразование IP-адресов в имена хостов. Если они уж так сильно вам необходимы при анализе логов, то можно определять их на стадии анализа, а не в процессе работы сервера. За разрешение имён хостов отвечает директива HostnameLookups, которая, вообще-то, по умолчанию и установлена в Off, однако проверьте это, если действительно считаете необходимым отключить преобразование.

Отключение использования .htaccess

Обработка файлов .htaccess выполняется Apache каждый раз при запросе данных. Мало того, что Apache должен загрузить этот файл, так ещё немало времени и ресурсов уходит на его обработку. Взгляните на ваш веб-сервер и пересмотрите необходимость в использовании файлов .htaccess. Если вам нужны различные настройки для разных каталогов, может быть реально будет их вынести в основной файл конфигурации сервера? А отключить обработку .htaccess можно директивой в конфигурации сервера:

По мотивам emergent.urbanpug.com




Немного об Apache и производительности: 4 комментария

  1. + за старание.

    Минусы:

    — В apache2 используется несколько разных способов создания процессов и потоков.

    В статье упомянут prefork, который является самым медленным.

    Я бы рекомендовал использовать worker, как баланс между скоростью и стабильностью.

    — Нет рекомендации использовать последнии версии apache.

    С новыми способами создания процессов/потоков.

    В lenny, мягко говоря, версии не первой свежести.

    — Не упомянут nginx, как отдатчик статики;

    — Не упомянуты варианты использования php через cgi, или fast-cgi.

    Судя по всему, опубликована статья 4-летней давности.

  2. XoRe, спасибо огромное за ваши замечания. Да, статья старенькая, это правда. Переводная просто. Ничего лучше не нашлось. Спасибо ещё раз, учту на будущее.

  3. Вы пишите:

    — отключение использования .htaccess

    А в реальном проекте с использованием apache без него можно обойтись? может быть я просто не знаю, подскажите.

Комментарии запрещены.