Лучше ли увеличить количество рабочих потоков или создать свой собственный пул потоков в Netty?

Question

Давайте предположим, что наш сервер Netty (4.1.32) отвечает на вызовы http.Предположим далее, что он должен выполнить определенные действия по блокировке, прежде чем на входящие запросы можно будет ответить, например, он должен выполнить исходящий вызов (используя другую библиотеку здесь) для загрузки внешних данных.

Количество потоков дляNioEventLoopGroup с постоянными соединениями dicusses

Что произойдет, если мой метод messageReceived заблокирует что-либо или займет много времени?

, на который @Maksym отвечает

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

Очевидно, что количество рабочих потоков ограничено.Таким образом, эффективная блокировка всех доступных рабочих потоков означает, что Netty будет ставить в очередь любые дальнейшие запросы, пока рабочие потоки не станут доступными.С другой стороны, перенос блокирующих действий на мои собственные потоки, как это было предложено, будет влиять на производительность при переключении потоков, а то, что в свою очередь будет блокироваться доступным оборудованием, - это мой собственный пул потоков.ИМХО использование собственного пула потоков только добавляет еще один уровень сложности, но не повышает производительность.Вместо этого я бы предпочел увеличить максимальное количество рабочих потоков и заставить Netty выполнять работу с очередями запросов.

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

Answer 1

Вы должны использовать свой собственный пул потоков, точка.Рабочие потоки Netty распределяются между многими соединениями. Если вы заблокируете обработку одного запроса, это повредит другим.Дизайн предполагает, что ваш код возвращается быстро, если вам нужно заблокировать, вы должны использовать отдельный поток для этого.То же самое применимо, если вам нужно выполнить действительно дорогостоящий расчет, сделать это в другом потоке и вернуть.

Если вы выполнили какое-либо программирование на Swing, вы можете сравнить его с потоком GUI.Если вы блокируете поток GUI, пользовательский интерфейс зависает и перестает отвечать на запросы.Не подходит для пользовательского интерфейса и не для высокопроизводительного сетевого приложения!

РЕДАКТИРОВАТЬ: просто чтобы быть супер четким, при классическом вводе-выводе один поток обычно назначается запросу, и если запрос блокирует это неконец света, если пул потоков достаточно велик, другие потоки могут обрабатывать другие запросы.С NIO вы не получаете поток для вашего запроса, вы вызываетесь потоком, который обрабатывает IO для многих запросов для обработки события, и вы должны сделать это как можно быстрее, чтобы поток мог перейти к другому.Запросы.Блокировка действительно вредна для сервера.