асинхронный — почему Apache Event MPM работает плохо?
Event MPM не совсем такой же, как Nginx, но был явно разработан, чтобы сделать keepalive более надежным и быстрее отправлять статические файлы. Насколько я понимаю, Event MPM немного неправильный, потому что:
- Хотя соединение передается в kqueue / epoll,
- некоторые очень важные модули, такие как mod_gzip и mod_ssl будут блокировать / потреблять поток до тех пор, пока не будет получен ответ,
- и это проблема для больших файлов, но, вероятно, не для сгенерированных PHP документов HTML и т. д.
К сожалению, Apache продолжает терять долю рынка, и большинство тестов являются проклятыми для события MPM. Являются ли тесты ошибочными или событие MPM действительно плохо работает с Nginx? Даже с этими ограничениями, при нормальном трафике (не вредоносном) и меньших файлах, он должен быть несколько конкурентоспособен с Nginx. Например, он должен быть конкурентоспособным при обработке документов, сгенерированных PHP, через php-fpm при медленных соединениях, потому что документ будет буферизироваться (даже если он ssl’d и gzip’d) и отправляться асинхронно. Соединения SSL и не-SSL, использующие сжатие или нет, не должны работать по-разному, чем в Nginx при такой рабочей нагрузке.
Так почему же он не светит в разных тестах? Что с этим не так? Или что не так с тестами? Использует ли крупный сайт его как обращение к органу власти, который он может выполнить?
Решение
Это медленнее, чем nginx, потому что Apache с событием MPM (очень) примерно эквивалентен управляемому событиями HTTP-прокси (nginx, varnish, haproxy) перед Apache с рабочим MPM. Событие является рабочий, но вместо того, чтобы передавать каждое новое соединение потоку в течение его времени жизни, потоки события MPM передают соединение вторичному потоку, который помещает его в очередь или закрывает, если keep-alive выключен или истек срок его действия.
Реальное преимущество события перед работником — это использование ресурсов. Если вам необходимо поддерживать 1000 одновременных подключений, рабочему MPM требуется 1000 потоков, в то время как событие MPM может обойтись с помощью 100 активных потоков и 900 свободных соединений, управляемых в очереди событий. Событие MPM будет использовать часть ресурсов рабочего MPM в этой гипотезе, но обратная сторона все еще существует: каждый из этих запросов обрабатывается отдельным потоком, который должен планироваться ядром и, как таковой, будет нести расходы переключение контекста.
С другой стороны, у нас есть nginx, который использует саму модель событий в качестве своего планировщика. Nginx просто обрабатывает как можно больше работы с каждым соединением, прежде чем перейти к следующему. Никакого дополнительного переключения контекста не требуется.
Единственный случай использования, когда событие MPM действительно сияет, — это обработка установки, в которой у вас есть тяжелое приложение, работающее в Apache, и для сохранения ресурсов потоков, которые простаивают во время поддержки активности, вы должны развернуть прокси (такой как nginx) перед апачем. Если ваш интерфейс не служил никакой другой цели (например, статический контент, проксирование на другие серверы и т. Д.), Событие MPM обрабатывает этот случай использования. красиво и устраняет необходимость в прокси.
Другие решения
Для меня доминирующие оперативные различия таковы, что в случае:
- обработчики (плагины, отвечающие за генерацию ответа) являются синхронными — если они выполняют вычисления или ввод / вывод, они связывают поток
- ядро должно использовать межпотоковые блокировки для защиты ключевых структур данных, потому что оно является многопоточным для поддержки многих из этих синхронных запросов
Вот почему на серверах с очень большими объемами, таких как nginx (или Apache Traffic Server или любой современный коммерческий / высокопроизводительный прокси-сервер), обычно выходят вперед.
IMO Пули в вашем вопросе немного не соответствуют действительности, SSL и deflate на самом деле не вносят существенного вклада в различия здесь, поскольку они оба являются фильтрами, которые на самом деле не способствуют проблемам масштабируемости или даже связывают httpd с его традиционными гарантиями API о Жизненный цикл запроса или подключения. Подобные фильтры (против обработчиков или основного фильтра, ответственного за низкоуровневый ввод / вывод), вероятно, наименее связаны с моделью обработки.
Но я также не думаю, что он выглядит так плохо по сравнению со всеми, кроме самых экстремальных рабочих нагрузок или крайне ограниченных систем. Большинство тестов, которые я видел, имеют крайне низкое качество по той или иной причине.
Я думаю, что в основном люди хотят, чтобы то, что они сегодня называют веб-сервером, было прокси для более сложного сервера приложений (Java EE, PHP и т. Д.), А сервер, предназначенный для наиболее эффективного перемещения ввода-вывода без использования API, получит преимущество. ,