Спросите о том, как работает причал, встроенный в maven.

Это случай преждевременной оптимизации и непонимания того, как на самом деле работает ни Jetty, ни ваше собственное веб-приложение.

Совет, не настраивайте преждевременно файл QueuedThreadPool.

Оставьте его по умолчанию, тестируйте и еще раз тестируйте, а затем проводите нагрузочное тестирование, затем снова проводите нагрузочное тестирование, но другим способом. Постоянно собирайте информацию о том, как ведет себя QueuedThreadPool по умолчанию.

Тогда и только тогда вы должны настроить QueuedThreadPool под свои нужды.

Но никогда не прекращайте следить за своим сервером и веб-приложением, так как вы будете часто настраивать свою конфигурацию. (особенно если вы настроите QueuedThreadPool меньше, чем по умолчанию)

Важно! Если вам нужно ограничить количество запросов или подключений или контролировать количество или скорость запросов или подключений, попытка сделать это на уровне ThreadPool никогда не сработает.

Эта диаграмма неверна (или устарела как минимум на 10 лет).

Начиная с Jetty 7, нет очереди соединений, нет разделения потоков Acceptors и Request.

Пул потоков (на самом деле это всего лишь java.util.concurrent.Executor) используется для ВСЕХ запросов потоков на сервере Jetty. Это может быть прием соединения, обработка управляемого селектора nio, обработка отдельных селекторов nio, обработка событий чтения из сети, обработка начальной отправки запроса, обработка событий записи из веб-приложения в сеть, обработка асинхронной обработки из Servlet 3.0, QoSFilter, DoSFilter, обработка асинхронного ввода-вывода из Servlet 3.1, обновленные соединения, веб-сокет, управление HttpSession, обработка горячего развертывания, сканирование байт-кода и т. д.

С ограничением в 50 максимальных потоков:

• Вам никогда не понадобится другой акцептор.
• Вы уморите клиентов голодом и создадите огромные проблемы.
• Типичная веб-страница, которую загружает браузер, будет использовать от 8 до 12 подключений, что означает, что в этой конфигурации с максимальным количеством потоков 50 можно будет обрабатывать от 4 до 6 клиентов одновременно.

Типы приложений, которые нуждаются в другом акцепторе, это те, которые обрабатывают огромное количество новых подключений (для Eclipse Jetty вам обычно нужен еще один акцептор, когда вы пересекаете порог в 30 000 новых подключений в секунду).

Количество акцепторов, которые использует Jetty, настраивается на уровне ServerConnector, а не на уровне ThreadPool.

Просмотрите конструкторы ServerConnector и выберите конструктор, наиболее подходящий для вашей среды.

@Joakim Erdfelt, большое спасибо за ответ!!

Мой сервер живет в микросервисах диаграммы, а не как веб-сервер, количество подключений не может достигать 30 000, которые могут быть Google ^.^.

Я просто хочу, чтобы последовательность задач вышла из веб-сервера на диаграмме, потому что я получил ответ TIMEOUT от сервера партнера, если не последовательность задач.

Время ответа около 10 секунд, поэтому потоки не должны быть заняты в минимальном потоке.

Я использовал:

<jetty.version>9.4.30.v20200611</jetty.version>

Я думаю, что приведенная выше диаграмма является ядром причала, потому что я все еще нахожу, что она позволяет это делать, но у меня есть диаграмма расширенного решения с конфигурацией моего сервера:

boolean checkOOM = threadPool.getThreadPoolBudget().check(StaticConfig.JETTY_MAX_THREADS);
LOGGER.info("check maxThread allow with memory : "+checkOOM);
if(!checkOOM) {
   LOGGER.info("please increase merory server or decrease maxThread.");
   System.exit(1);
}
//depend info system
//get core processor of server
int coreProcessor = Runtime.getRuntime().availableProcessors();
LOGGER.info("coreProcessor : "+coreProcessor);

Server server = new Server(threadPool);
int port = 0;

try {
   port = Integer.parseInt(System.getProperty("server.port"));
} catch (NumberFormatException ex) {
  LOGGER.error("Property server.port not found. " + ex.getMessage(), ex);
  System.exit(1);
}
// if acceptor 0 then the selector threads are used to accept connections
// selector backup for acceptor
// only init with limit system
try (ServerConnector httpConnector = new ServerConnector(server, coreProcessor, coreProcessor)) {
    httpConnector.setAcceptQueueSize(StaticConfig.JETTY_MAX_QUEUED);
    LOGGER.info("acceptors : "+httpConnector.getAcceptors());
    LOGGER.info("queueSize : "+httpConnector.getAcceptQueueSize());
    httpConnector.setPort(port);
    server.setConnectors(new Connector[]{httpConnector});
} catch (Exception e) {
    LOGGER.error(e.getMessage(), e);
    System.exit(1);
}
server.start();
server.join(); << init thread pool.

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

Я использовал ServerConnector, аналогичный вашему предложению.

Я пытаюсь использовать QueueThreadPool по умолчанию (сервер конструктора инициализации не вводит параметр threadPool в приведенном выше коде), я печатаю журнал как 4 потока инициализации:

int cntThread = server.getThreadPool().getThreads();
LOGGER.info("idleThread server : "+cntThread);

Мне просто интересно, как правильно работает роль пула потоков на диаграмме!

ps: у вас есть информация о новой схеме текущей версии причала?

Большое спасибо.

Уважаемый @Joakim Erdfelt,

Я применяю приведенную выше конфигурацию, но у меня проблема с памятью сервера (при текущем наборе 3 ГБ), общий запрос за время обработки около 2500!!

Я не понимаю, почему память полная? потому что, когда поток закрывается, когда HeapByteBuffer освобождается!

И у меня есть открытые 8 акцепторов и 8 селекторов, когда класс Server пакета причала я вижу, что селектор комментариев будет использовать, когда акцептор заполнен, но я отслеживаю потоки, которые я видел, селектор используется, акцептор свободен :(

пожалуйста, предложите мне, спасибо.