Apache: prefork & mpm-worker

tux-apache

Скорее всего вы уже имеете базовые знания о принципах работы и возможностях http сервера Apache, однако все равно начнем с небольшого экскурса в теорию. Большинство администраторов, которые работают с Apache, знают о двух моделях, с помощью которых Apache сервер отвечает на запросы — это prefork и mpm-worker.

Типы мультипроцессовых модулей.

Мультипроцессовых модулей (Multi-Processing Module) много (если судить по википедии), относительной популярностью пользуются три:

    • prefork — классический MPM, реализующий модель мульти-процессинга. Каждый поток обрабатывается в отдельном процессе. Другими словами — «отдельный процесс для запроса». При такой схеме каждый процесс апача использует уникальные от других процессов буферами, процессорные мощности и память. Apache поддерживает «простой» процесса, как результат из-за большого количества ожидающих запросов, может наступить нехватка ресурсов. Не самый производительный вариант, но наиболее стабильный. Используется по умолчанию.
apache prefork MPM

apache prefork MPM

    • worker — MPM, основанный на потоках. Сервер порождает несколько процессов, по несколько потоков в каждом. Один запрос — один поток. Производительнее prefork, но менее стабилен.

apache worker mpm

  • event — событийный MPM. Вместо потоков запросы обрабатываются, используя событийную модель, похожую на ту, что применяется в nginx. Наиболее производительный MPM, но и наименее стабильный (находится в экспериментальной стадии разработки).

tux_apache

Для понимания процесса, необходимо знать о типах «воркеров».

Основных типов два — это процесс и поток,  для улучшения производительности иногда используют оба типа одновременно, порождая несколько процессов и кучу потоков в каждом:

  • Процесс: Различные worker’ы могут быть процессами. В этом случае они не взаимодействуют между собой, и данные различных worker’а полностью независимы друг от друга.
  • Поток:  Потоки, в отличие от процессов, имеют общие, разделяемые структуры данных. В коде worker’а должна быть реализована синхронизация доступа, чтобы одновременная запись одной и той же структуры не привела к хаосу.

Как определить MPM с которым работает Ваш веб сервер?

Заходим на сервер по SSH:

apachectl -t -D DUMP_MODULES | grep mpm
 mpm_prefork_module (static)
Syntax OK

# httpd -V | grep MPM
Server MPM:     Prefork
 -D APACHE_MPM_DIR="server/mpm/prefork"

Переходим с prefork на worker на Apache.

В /etc/sysconfig/httpd снимаем комментарий со строчки и перегружаем демона:

HTTPD=/usr/sbin/httpd.worker

В конфигурации apache настраиваем режим работы модуля:

StartServers       1
MaxClients         50
MinSpareThreads     15
MaxSpareThreads     35
ThreadsPerChild     25
MaxRequestsPerChild  2000

  1. StartServers – количество процессов запускаемых при старте
  2. MinSpareThreads/MaxSpareThreads – количество свободных потоков. Свободные потоки – это сумма потоков во всех процессах
  3. MaxClients – максимально количество одновременных клиентов, то есть максимальное количество потоков во всех процессах
  4. ThreadsPerChild – количество потоков создаваемое каждым процессом,  то есть если мы разделить MaxClients на ThreadsPerChild, то получим число процессов которое будет создано при максимальной загрузке.
  5. ServerLimit – количество максимальных процессов.  Число должно быть не меньше MaxClients/ThreadsPerChild – числа процессов при максимальной нагрузке.
  6. MaxRequestsPerChild – через сколько запросов уничтожается процесс.

Скорость обработки запросов.

average-request-time-graph-540x324

ab -c 1 -n 10 http://example.com/index.html

Опция -c задает количество одновременных соединений, -n общее количество запросов.

В итоге получим среднюю суммарная скорость запроса в миллисекундах.

При с=1 — поведение характерно для единичного (случайного) посещения сайта, т.е. низкой нагрузки.  Для дальнейшего тестирования увеличиваем количество моделируемых одновременных пользователей до ста.

average-request-table-285x300

Из статистики видим, имеем не такую уж большую разницу, для всех серверов. Расхождение в пределах 10% друг от друга.

Во втором тесте измерили время, требуемое серверу, для обработки большого количества запросов.

Запрашивали порядка 400 файлов с 1000 одновременно открытых  соединений, т.е.  порядка 400 000 статических страниц.

siege -b -c 1000 -r 403 —file=urls.txt

По статистике получили схожую картину.

delivery-time-graph-540x305

delivery-time-table-300x257

Однако по процессору и памяти результаты разнились намного сильнее.

Для Nginx и Lighttpd загрузка процессора составила 40-50%, в то же время для остальных демонов загрузка процессора была порядка 70-90%.

Самое большое потребление памяти было во время работы Apache PreFork — 328 Мб оперативной памяти, самое низкое было для Apache worker — 237 Мб оперативной памяти.

Вы можете оставить комментарий ниже.
  • саша

    сейчас по умолчанию — event