влияет ли медленное соединение на производительность netty?

КОД-1

new NioServerSocketChannelFactory(Executors.newCachedThreadPool(), Executors.newCachedThreadPool(),WORKER_SIZE)

КОД-2

OrderedMemoryAwareThreadPoolExecutor executor = new OrderedMemoryAwareThreadPoolExecutor(48, 0, 0, 1, TimeUnit.SECONDS);
pipeline.addLast("executor", new ExecutionHandler(executor));

Если размер пула рабочих потоков ввода-вывода (по умолчанию 2 * количество процессоров) можно установить из CODE-1, какова цель добавления исполнителя (пула потоков) в конвейер в CODE-2?

Операции ввода-вывода выполняются из рабочих потоков. Означает ли это, что клиент с медленным соединением или плохой сетью удерживает рабочий поток ввода-вывода до тех пор, пока данные не будут полностью отправлены? Если да, то увеличение WORKER_SIZE поможет мне предотвратить задержки?


person WorM    schedule 09.01.2012    source источник


Ответы (2)


Медленные соединения обычно не влияют на потоки Netty в NIO (см. примечание об обновлении).

Некоторые моменты о внутренних потоках сервера Netty

  • по умолчанию будет только один Boss Thread на порт сервера, и он примет соединение и передаст соединение рабочему потоку.

  • если быть точным: WORKER_SIZE — это максимальное количество исполняемых модулей NioWorker, которое может иметь сервер. например, если сервер имеет только одно соединение, то будет 1 рабочий поток. Если число подключений увеличивается и их нельзя назначить следующему рабочему процессу (активные соединения > WORKER_SIZE), то соединения будут назначаться рабочему процессу в циклическом режиме.

Если размер пула рабочих потоков ввода-вывода (по умолчанию 2 * количество процессоров) можно установить из CODE-1, какова цель добавления исполнителя (пула потоков) в конвейер в CODE-2?

Если ваши восходящие задачи блокируются, вы должны выполнять их в отдельном пуле потоков, используя обработчик выполнения. В противном случае чтение/запись Nio не будет работать вовремя (задержка?). Я думаю, что наличие обработчика выполнения поможет уменьшить задержку, чем установка большого значения для WORKER_SIZE.

Операции ввода-вывода выполняются из рабочих потоков. Означает ли это, что клиент с медленным соединением или плохой сетью удерживает рабочий поток ввода-вывода до тех пор, пока данные не будут полностью отправлены? Если да, то увеличение WORKER_SIZE поможет мне предотвратить задержки?

Вообще говоря, увеличение WORKER_SIZE >= количество процессоров * 2 не помогает, потому что NIO не блокируется и, если я не ошибаюсь, интенсивно использует ЦП. Для задачи с интенсивным использованием ЦП в основном выбирается число потоков ЦП * 2.

Обновление:

NioWorker запускает цикл с selector.select(500 мс) для получения OP_READ, selector.select с тайм-аутом блокирующего вызова, и если большинство соединений медленные, производительность может снизиться? Вы можете уменьшить время ожидания в org.jboss.netty.channel.socket.nio.SelectorUtil.java и протестировать.

person Jestan Nirojan    schedule 09.01.2012
comment
jestan, я в замешательстве. поток-босс передает запрос рабочему потоку ввода-вывода. рабочий поток запускает обработчик выполнения. если пул выполнения установлен для обработчика, запрос продолжается в другом потоке, так что рабочий поток ввода-вывода освобождается. я прав ? - person WorM; 11.01.2012

Пулы потоков, которые вы добавляете в CODE-1, предназначены для потоков-боссов и рабочих потоков. Босс-потоки принимают соединения и передают их рабочему потоку для обработки.

Исполнитель, который вы добавляете в CODE-2, предназначен для обработки сообщений, прочитанных рабочими потоками.

Медленные соединения не повлияют на производительность, поскольку вы используете неблокирующую архитектуру (NIO), которая в Netty настроена на неблокировку (может, если захочет).

person ClickerMonkey    schedule 09.01.2012
comment
могу ли я сказать, что поток босса передает запросы рабочему потоку ввода-вывода (выбранному из пула с размером: WORKER_SIZE в CODE-1). Рабочий поток ввода-вывода передает прочитанные сообщения другому потоку для обработки (который устанавливается в CODE-2). - person WorM; 09.01.2012