Это канонический вопрос о выборе правильного Apache httpd MPM.
Я немного запутался между различными MPM, предлагаемыми Apache - 'worker', 'event', 'prefork' и т. Д.
Каковы основные различия между ними, и как я могу решить, какой из них будет лучше для данного развертывания?
apache-2.2
httpd
mpm-worker
mpm-prefork
Тиффани Уокер
источник
источник
Ответы:
Есть целый ряд модулей MPM (Мульти-Модули обработки), но на сегодняшний день наиболее широко используется (по крайней мере , на * NIX платформах) являются тремя основными из них:
prefork,worker, иevent. По сути, они представляют собой эволюцию веб-сервера Apache и различные способы, которыми был построен сервер для обработки HTTP-запросов в рамках вычислительных ограничений времени в течение его длинной (с точки зрения программного обеспечения) истории.preforkmpm_preforkэто .. хорошо .. это совместимо со всем. Он обслуживает несколько дочерних процессов для обслуживания запросов, и дочерние процессы обслуживают только один запрос за раз. Поскольку там находится серверный процесс, готовый к действию, и ему не нужно иметь дело с маршалингом потоков, он на самом деле быстрее, чем более современные многопоточные MPM, когда вы работаете только с одним запросом за раз - но одновременные запросы страдают, так как они вынуждены ждать в очереди, пока серверный процесс не будет свободным. Кроме того, пытаясь увеличить количество дочерних процессов prefork, вы легко отнимите серьезную оперативную память.Вероятно, не рекомендуется использовать prefork, если вам не нужен модуль, который не является потокобезопасным.
Используйте if: Вам нужны модули, которые ломаются при использовании потоков, например
mod_php. Даже тогда рассмотрите возможность использования FastCGI иphp-fpm.Не используйте if: Ваши модули не прерываются в потоке.
workermpm_workerиспользует многопоточность - это большая помощь для параллелизма. Рабочий раскручивает некоторые дочерние процессы, которые, в свою очередь, раскручивают дочерние потоки; По аналогии с prefork, некоторые резервные потоки, если это возможно, остаются готовыми для обслуживания входящих соединений. Этот подход намного лучше в оперативной памяти, поскольку счетчик потоков не имеет непосредственного отношения к использованию памяти, как подсчет серверов в prefork. Кроме того, он гораздо проще обрабатывает параллелизм, поскольку соединениям просто нужно ждать свободного потока (который обычно доступен) вместо резервного сервера в prefork.Используйте if: вы используете Apache 2.2 или 2.4 и используете в основном SSL.
Не используйте if: вы действительно не ошибетесь, если вам не нужен prefork для совместимости.
Однако обратите внимание, что шаги присоединяются к соединениям, а не к запросам - это означает, что соединение keep-alive всегда удерживает поток до его закрытия (что может быть долгим, в зависимости от вашей конфигурации). Вот почему у нас есть ..
eventmpm_eventочень похож на рабочий, структурно; он только что был переведен из «экспериментального» в «стабильный» статус в Apache 2.4. Большая разница состоит в том, что он использует выделенный поток для работы с поддерживаемыми соединениями и передает запросы дочерним потокам только тогда, когда запрос фактически сделан (что позволяет этим потокам освободиться сразу же после завершения запроса). Это отлично подходит для одновременной работы клиентов, которые не обязательно все активны одновременно, но время от времени делают запросы и когда клиенты могут иметь длительный тайм-аут активности.Исключением здесь являются SSL-соединения; в этом случае он ведет себя идентично рабочему (приклеивая данное соединение к данному потоку, пока соединение не закроется).
Используйте if: вы на Apache 2.4 и любите потоки, но вам не нравится, когда потоки ожидают незанятых соединений. Все любят темы!
Не используйте if: вы не используете Apache 2.4 или вам нужен prefork для совместимости.
В современном мире Slowloris , AJAX и браузеров, которым нравится мультиплексировать 6 TCP-соединений (с поддержкой keep-alive) на ваш сервер, параллелизм является важным фактором, способствующим хорошему масштабированию и масштабированию вашего сервера. В этом отношении история Apache связала его, и, хотя она по-прежнему не соответствует стандартам nginx или lighttpd с точки зрения использования ресурсов или масштаба, очевидно, что команда разработчиков работает над созданием веб-сервера, который по-прежнему актуален в сегодняшнем мире с высоким уровнем запросов-параллелизма.
источник
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.Вот хорошее объяснение того, как это работает с GIF:
https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/
Вкратце: если вы используете 2.4 и вам нужен httpd в качестве обратного прокси (диспетчера), значит, ваш выбор - Event MPM
источник
По состоянию на февраль 2018 года в документации по Apache 2.4 для Event MPM говорится, что использование Apache в качестве прокси не позволит «улучшенной обработке соединений», начиная с 2.4.24, работать так, как задумано. Смотрите раздел Ограничения .
Проблема заключается в том, что в качестве прокси-сервера рабочий не может сказать, где находится конец ответа, и ему придется ждать, пока не будет виден весь ответ, прежде чем вернуть управление слушателю.
По этой причине кажется, что использование модели Worker лучше всего подходит для случаев, когда в качестве прокси используется Apache. Мне не совсем понятно, есть ли преимущества в модели событий в прокси-среде, но, возможно, есть.
источник
В основном зависит от того, какие модули Apache вы хотите использовать. Я думаю, что рабочий, как правило, является выбором по умолчанию, но некоторые (старые) модули требуют разветвления и зависят от prefork.
Если у вас нет предпочтений, я рекомендую вам использовать предпочтительную зависимость из вашего дистрибутива ОС. Например, Ubuntu по умолчанию установит mpm-worker при установке Apache2.
источник