Как выбрать максимальное количество потоков для контейнера сервлетов HTTP?

Question

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

Существует ли исследованная формула для определения максимального числа потоков по некоторым легко измеримым характеристикам остальной части установки?

Answer 1

Очень простой и примитивный:

max_number_of_threads = number_of_CPUs * C

Где C зависит от других факторов вашего приложения: -)

Задайте себе следующие вопросы:

• Будет ли ваше приложение интенсивно использовать процессор (ниже C) или тратить больше всего времени на ожидание третьей системы (выше C)?
• Требуется ли вам более быстрое время отклика (ниже C) или вы можете обслуживать сразу несколько пользователей, даже если каждый запрос занимает больше времени (выше C).

Обычно я устанавливаю C довольно низко, например 2 - 10.

Answer 2

Я понимаю, что в то время, когда задавался этот вопрос, Servlet 3.0 не было. Но я подумал, что должен записать в этом вопросе возможность выполнения асинхронной обработки в контейнере Servlet с использованием Servlet 3.0. Это может помочь кому-то, кто сталкивается с этим вопросом. Излишне говорить, что для Servlet 3.0 достаточно ресурсов, которые указывают на то, что основные потоки сервлетов теперь меньше подвержены давлению! А у Jetty есть асинхронные аналоги на тот случай, если не нужно использовать Servlet 3.0 API как таковой.

Answer 3

нет там нет. Ограничьте количество потоков и контролируйте их, чтобы не превышать системные ресурсы, ограничение Java обычно составляет около 100-200 активных потоков.

Хороший способ сделать это - использовать Executors от java.util.concurrent .

Answer 4

Спасибо. Я прочитал это, поскольку там не было простой формулы. : - (

(Мое приложение является средством проверки HTML5. Иногда оно явно ожидает на внешних серверах. Однако трудно точно определить, действительно ли оно связано с ЦП либо самостоятельно, либо через сборщик мусора.)

Answer 5

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

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

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

Answer 6

Ответ зависит от максимального количества одновременных соединений, которые вы ожидаете обработать. Вы должны разрешить столько потоков, сколько ожидаемых соединений.

andreasmk2 неверно указывает количество потоков. Я запускал приложения с 1000 потоков и не имел проблем с системными ресурсами; конечно, это зависит от особенностей вашей системы. Вы столкнулись с ограничением system , а не с ограничением Java .