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

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

prefork

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

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

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

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

worker

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

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

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

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

event

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

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

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

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

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

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

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

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

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

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

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

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

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