Вопрос: Как выбрать, какой Apache MPM использовать?


Это Канонический вопрос о выборе правильного Apache httpd MPM.

Я немного запутался между различными MPM, предлагаемыми Apache - «работником», «событием», «предкром» и т. Д.

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


238
2018-04-26 18:40


Источник


Если вы поддерживаете mod_php, вы делаете предпросмотр. - Zoredache
@Zoredache:? она никогда не упоминала PHP, и даже если бы она это сделала, mod_php исключил бы событие. Или вы все еще цепляетесь за замечание, сделанное RL 8 лет назад? Последняя ошибка, зарегистрированная в PHP, связанная с threaded apache, была в 2005 году. - symcbean
Извините, мне нужно проголосовать, чтобы закрыть это - слишком широкий вопрос, чтобы ответить здесь. - symcbean
@symcbean Re: PHP и Threads - ядро ​​PHP в настоящее время является потокобезопасным, но многие другие вещи, которые вы найдете, компилируют людей, это не так. Я был укушен еще в прошлом году, так что это очень «тест (широко), прежде чем полагаться на него в производстве». - voretaq7
В зависимости от используемой ОС вы можете даже не иметь всех этих параметров со стандартной установкой. - John Gardeniers


Ответы:


Существует ряд Модули MPM (Многопроцессорные модули), но наиболее широко используемыми (по крайней мере, на платформах * nix) являются три основных: prefork, worker, а также event, По сути, они представляют собой эволюцию веб-сервера Apache и различные способы создания сервера для обработки HTTP-запросов в рамках вычислительных ограничений времени в течение долгого (в программном плане) истории.


prefork

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

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

Используйте, если: Вам нужны модули, которые ломаются при использовании потоков, например mod_php, Даже тогда подумайте об использовании FastCGI и php-fpm,

Не используйте, если: Ваши модули не будут разбиваться на потоки.

worker

mpm_worker использует потоки - это большая помощь для параллелизма. Работник отталкивает некоторые дочерние процессы, которые, в свою очередь, оттягивают дочерние потоки; как и в предфильме, некоторые запасные потоки по возможности готовы, чтобы обслуживать входящие соединения. Этот подход намного более удобен в ОЗУ, поскольку количество потоков не имеет прямого отношения к использованию памяти, как это делает счетчик серверов в предпродаже. Он также упрощает параллелизм, так как соединения просто должны ждать свободного потока (который обычно доступен) вместо резервного сервера в предпродаже.

Используйте, если: Вы находитесь на Apache 2.2 или 2.4, и вы работаете в основном с SSL.

Не используйте, если: Вы действительно не ошибетесь, если вам не нужна предварительная версия для совместимости.

Однако обратите внимание на то, что протекторы прикреплены к связи и не Запросы - это означает, что соединение keep-alive всегда удерживает поток до тех пор, пока он не будет закрыт (что может быть длительным, в зависимости от вашей конфигурации). Вот почему у нас есть ..

event

mpm_event очень похож на рабочего, структурно; его просто перевели с «экспериментального» на «стабильный» статус в Apache 2.4. Большая разница заключается в том, что он использует выделенный поток для работы с поддерживаемыми соединениями, а руки запрашивают до дочерних потоков только тогда, когда запрос действительно был сделан (позволяя этим потокам освобождать резервную копию сразу после завершения запроса). Это отлично подходит для параллелизма клиентов, которые не всегда являются активными одновременно, но делают случайные запросы и когда у клиентов может быть длительный тайм-аут.

Исключение составляет SSL-соединение; в этом случае он ведет себя одинаково с рабочим (приклеивание данного соединения к данному потоку до закрытия соединения).

Используйте, если: Вы находитесь на Apache 2.4 и как потоки, но вам не нравится, когда потоки ожидают простоя. Все любят темы!

Не используйте, если: Вы не на Apache 2.4, или вам нужна предварительная версия для совместимости.


В современном мире Slowloris, AJAX и браузеров, которые любят мультиплексировать 6 TCP-соединений (с сохранением, конечно,) на ваш сервер, параллелизм является важным фактором для масштабирования и масштабирования вашего сервера. История Apache связала это в этом отношении, и, хотя на самом деле все еще не соответствует номинальным значениям nginx или lighttpd с точки зрения использования ресурсов или масштаба, ясно, что команда разработчиков работает над созданием веб-сервера, который все еще имеет значение в сегодняшнем мире с высоким запросом-параллелизмом.


391
2018-04-27 02:27



эпический - Mark Henderson♦
@MarkHenderson Канонический даже. - voretaq7
-1: IME, рабочий только уменьшает размер footprint httpd в области 15% (IIRC Linux сообщает COW в RSS, что делает pre-fork выглядеть так, как если бы он использовал гораздо больше памяти, чем он). Существует незначительная разница между ядром для процесса и потоком NPTL. Это далеко от землетрясения. Я не понимаю, почему вы думаете, что ожидание и выделение потока более эффективно при расписании, чем ожидание / планирование процесса (pre-forked). И вы не считаете, что SSL в целом не работает. - symcbean
@symcbean Итак, вы говорите, что 15% использования ОЗУ не значительны? Это нормально, но мое мнение было бы иначе. Требования к производительности параллелизма не являются моими собственными. Видеть Вот, И разница SSL четко прописана в документации для события MPM: The improved connection handling does not yet work for certain connection filters, in particular SSL. For SSL connections, this MPM will fall back to the behaviour of the worker MPM and reserve one worker thread per connection. - Shane Madden♦
@ShaneMadden `, и хотя он по-прежнему не соответствует параметрам nginx или lighttpd с точки зрения использования ресурсов или масштабирования. Я использовал apache для обеих этих систем. - Kelly Elton


В основном зависит от того, какие модули Apache вы хотите использовать. Я думаю, что рабочий обычно является выбором по умолчанию, но некоторые (более старые) модули требуют разветвления и зависят от предка.

Если у вас нет предпочтений, я рекомендую вам перейти с предпочтительной зависимостью от вашего дистрибутива ОС. Например, Ubuntu будет по умолчанию устанавливать mpm-worker при установке Apache2.


5
2018-04-26 19:32





Вот хорошее объяснение того, как это работает с gifs:

https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/

Вкратце: если вы 2,4 и вам нужен httpd как обратный прокси (диспетчер), поэтому ваш выбор Событие MPM


4
2018-06-21 13:10





По состоянию на февраль 2018 года в документации Apache 2.4 для Event MPM говорится, что использование Apache в качестве прокси-сервера будет поддерживать «улучшенную обработку соединения» с 2.4.24 от работы в соответствии с проектом. См. Ограничения раздел.

Проблема заключается в том, что, как прокси-сервер, рабочий не может определить, где заканчивается ответ, и будет вынужден ждать, пока весь ответ не появится, прежде чем возвращать управление слушателю.

По этой причине кажется, что использование модели Worker может быть лучше всего, когда apache используется как прокси. Мне не совсем ясно, есть ли преимущества для модели событий в прокси-среде, но, возможно, есть.


3
2018-02-14 15:01