Что ограничивает производительность конфигурации Apache с большим количеством потоков?

Мы экспериментировали с конфигурацией Apache 2.2 и mod_wsgi в Linux 3.8, чтобы проверить его поведение в условиях интенсивного параллельного трафика. Мы использовали ApacheBench (v2.3) для создания трафика с той же машины.

Мы получили установку, работающую довольно хорошо с 1000 потоков (10 процессов со 100 потоками), но столкнулись с проблемами при попытке масштабирования оттуда. С 10000 потоков (10 процессов 1000 потоков) сервер действительно стал медленнее и начал работать очень плохо с тем же количеством одновременных запросов.

Что является ограничивающим фактором для производительности с большим количеством потоков Apache? Почему 10000 потоков работают хуже, чем 1000 потоков? Что вообще ограничивает количество потоков? Мы понимаем, что в обычных веб-сервисах 10000 одновременных подключений - это не повседневный бизнес, но мы пытаемся лучше понять масштабируемость веб-серверов и различные типы веб-серверов.

Вот наша настройка рабочего MPM на 1000 потоков, которая работает очень хорошо.

<IfModule mpm_worker_module>
    StartServers           10
    MinSpareThreads      1000
    MaxSpareThreads      1000
    ThreadLimit          1000
    ThreadsPerChild       100
    MaxClients           1000
    MaxRequestsPerChild     0
</IfModule>

Настройка mpm worker на 10000 потоков. Эта установка была в 5 раз медленнее.

<IfModule mpm_worker_module>
    StartServers           10
    MinSpareThreads     10000
    MaxSpareThreads     10000
    ThreadLimit         10000
    ThreadsPerChild      1000
    MaxClients          10000
    MaxRequestsPerChild     0
</IfModule>

apache mod-wsgi apachebench
person Rubinous    schedule 28.07.2013    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Я даже не уверен, с чего начать, почему использование такого количества потоков в Apache - плохая идея. Я бы посоветовал вам для начала посмотреть мои выступления на PyCon:

Короткий ответ заключается в том, что если вам действительно необходимо обрабатывать большое количество действительно одновременных длительных запросов на одном сервере, вам, вероятно, не следует использовать Apache. Вы должны использовать систему на основе событий (асинхронную) для тех конкретных запросов, которые имеют эти нестандартные требования. Другими словами, вам не нужно переключать все ваше приложение на асинхронную модель, вместо этого вам нужно вертикально разделить ваше приложение и выделить подмножества URL-адресов, которые имеют требования, отличные от остальной части вашего приложения. Таким образом, вы можете адаптировать хостинг к требованиям каждого из них и не заставлять все ваше приложение работать в условиях ограничений, налагаемых небольшой частью вашего приложения.

На самом деле, большую часть времени, когда люди думают, что им нужно иметь возможность обрабатывать такое безумное количество одновременных запросов на одном сервере, они этого не делают. Для запросов с коротким временем отклика для обработки 10000 запросов в секунду не требуется 10000 потоков. Это связано с тем, что в каждом временном интервале в 1 секунду вы можете обработать более 1 запроса.

Единственная вещь, которая может облажаться, - это медленные клиенты, которые остаются в живых. Это убийца для Apache. Итак, вставьте перед ним nginx в качестве прокси и отключите keep alive в Apache, но оставьте keep alive в nginx. Использование nginx в качестве прокси изолирует Apache от медленных клиентов и позволит ему лучше работать с меньшими ресурсами. Это связано с тем, что запрос передается Apache только тогда, когда он обычно имеет всю информацию в запросе, чтобы позволить ему немедленно обработать запрос. Таким образом, он не привязан и не тратит ресурсы на ожидание медленного клиента.

Если у вас есть это требование для очень длительных запросов (длительный опрос) для подмножества запросов, тогда используйте прокси-сервер nginx только для этих URL-адресов на отдельный сервер на основе асинхронного режима. Таким образом, вам не придется иметь дело с болью от использования асинхронных систем в остальной части вашего обычного веб-приложения.

Все это сказано, также помните, что веб-сервер обычно не будет вашим узким местом. Кого волнует, может ли сервер обрабатывать 10000+ запросов в секунду, если ваш фактический стек веб-приложений, включая базу данных, может обрабатывать только 10 запросов в секунду. Это будет вашей реальной проблемой, и если вы не улучшите производительность своего веб-приложения, настройка веб-сервера не будет иметь никакого значения. Единственным решением было бы горизонтальное масштабирование и наличие более одного хоста и балансировки нагрузки между ними.

Чтобы найти настоящие узкие места, вам понадобится мониторинг производительности вашего реального приложения с реальным трафиком от реальных пользователей. Вы можете узнать больше о мониторинге производительности в моих выступлениях.

person Graham Dumpleton    schedule 28.07.2013
comment
Ваш ответ был очень поучительным, спасибо. Надеюсь, эти ссылки PyCon скоро появятся. Но. Хотя наша общая цель на самом деле состоит в том, чтобы понять теорию различных типов веб-серверов (чему очень помог ваш ответ), с помощью этого вопроса SO мы стремимся понять ограничения количества потоков на веб-сервере, основанном на потоках. Это физическая память? Или, возможно, это связано с накладными расходами на переключение контекста? - person Rubinous; 29.07.2013
comment
Ссылки уже должны работать. Для Python, какие ограничения зависят от приложения. Может быть памятью, может быть количеством одновременных запросов, может быть конфликтом мьютекса GIL в потоках. В игру может входить множество факторов. - person Graham Dumpleton; 30.07.2013
comment
@GrahamDumpleton Это 2021 год, и ваши ссылки не работают. Я бы хотел, чтобы вы разместили эти разговоры на YouTube. Пожалуйста, поделитесь новой ссылкой, если сможете. Спасибо - person Medical Doctor - Programmer; 11.06.2021