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

Question

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

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

Answer 1

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

max_number_of_threads = количество_CPU * C

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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