Спросите, как работает пристань, встроенная в maven - PullRequest
Новая
       86

Спросите, как работает пристань, встроенная в maven

1 голос
/ 17 июня 2020

Я использовал причал в проекте maven.

Он работает с потоком ниже:

diagram

Я перезаписываю QueueThreadPool класса сервера причала: 

QueuedThreadPool threadPool = new QueuedThreadPool(StaticConfig.JETTY_MAX_THREADS, 
StaticConfig.JETTY_MIN_THREADS, StaticConfig.JETTY_IDE_TIMEOUT, 
new BlockingArrayQueue<Runnable>(maxCapacity));

с JETTY_MAX_THREADS=50, JETTY_MIN_THREADS=5

, но у меня есть 5 потоков, созданных в мониторе при запуске сервера: 

xxx_thread-14
xxx_thread-15
xxx_thread-16
xxx_thread-17-acceptor-0@3d01ec3d-ServerConnector@11758f2a{HTTP/1.1, (http/1.1)}{0.0.0.0:90}
xxx_thread-18

потоки 14,15,16,18 - это потоки в пуле потоков (диаграмма img)? что такое очередь подключения?

Как создать потоки приемника mutils?

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

Спасибо очень нравится.

Ответы [ 3 ]

1 голос
/ 23 июня 2020

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

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

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

Затем, и только тогда, вы должны настроить QueuedThreadPool в соответствии со своими потребностями.

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

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

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

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

Пул потоков (который на самом деле представляет собой просто java.util.concurrent.Executor) используется для ALL потоков потоков на сервере Jetty. Это может быть прием соединения, обработка управляемого селектора nio, обработка отдельных селекторов nio, обработка событий чтения из сети, обработка начальной отправки запроса, обработка событий записи из веб-приложения в сеть, обработка asyn c обработка из Servlet 3.0, QoSFilter, DoSFilter, обработка asyn c I / O из Servlet 3.1, обновленные соединения, веб-сокет, управление HttpSession, обработка горячего развертывания, сканирование байт-кода и т. д. c.

С ограничение в 50 макс. потоков:

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

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

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

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

0 голосов
/ 26 июня 2020

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

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

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

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

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

0 голосов
/ 24 июня 2020

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

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

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

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

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

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

Я думаю, что приведенная выше диаграмма является ядром причала, потому что я все еще считаю, что она позволяет это делать, но у меня есть предварительная диаграмма решения с config my server: 

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.

Выше инициализации кода с разрешением config на запущенном сервере, у меня будут акцепторы номеров coreProcessor и резервные копии селекторов номеров coreProcessor для акцепторов.

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

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

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

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

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

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

...