задержка в netty из-за передачи запросов от потока босса к рабочему потоку? - PullRequest
Новая
       13

задержка в netty из-за передачи запросов от потока босса к рабочему потоку?

4 голосов
/ 28 декабря 2011

У меня есть несколько вопросов о Netty (на стороне сервера), приложениях TCP / IP;

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

Я использую: 

new OrderedMemoryAwareThreadPoolExecutor(350, 0, 0, 1, TimeUnit.SECONDS);

На самом деле я установил максимальное число потоков 350, так как не уверен насчет оптимального числа. Я регистрирую количество одновременных рабочих потоков каждую минуту, и кажется, что среднее значение слишком низкое (едва превышает 10). Поэтому я уменьшу это число, так как оно не требуется.

Есть ли другие параметры, важные моменты, о которых я должен знать, чтобы добиться максимальной производительности?

bootstrap.setOption("tcpNoDelay", true); - Есть ли недостатки в настройке этого параметра? Учитывая, что время доставки очень важно.

Исполнитель пула потоков: 

OrderedMemoryAwareThreadPoolExecutor executor = new OrderedMemoryAwareThreadPoolExecutor(48, 0, 0, 1, TimeUnit.SECONDS);

Вот мой трубопроводный завод: 

    ChannelPipeline pipeline = pipeline();
    pipeline.addLast("frameDecoder", new DelimiterBasedFrameDecoder(GProperties.getIntProperty("decoder.maxFrameLength", 8000 * 1024), Delimiters.nulDelimiter()));
    pipeline.addLast("stringDecoder", new StringDecoder( CharsetUtil.UTF_8 ));      
    pipeline.addLast("frameEncoder", new NullTermMessageEncoder());
    pipeline.addLast("stringEncoder", new JSONEncoder( CharsetUtil.UTF_8 ));
        pipeline.addLast("timeout", new IdleStateHandler(idleTimer, 42 , 0, 0));
    pipeline.addLast("executor", new ExecutionHandler(executor));
    pipeline.addLast("handler", new GServerHandler());

и ServerBootstrap: 

gServerBootstrap = new ServerBootstrap(new NioServerSocketChannelFactory(Executors.newCachedThreadPool(), Executors.newCachedThreadPool()));
        gServerBootstrap.setPipelineFactory(new GServerPipelineFactory());
                gServerBootstrap.setOption("backlog", 8129);
                gServerBootstrap.setOption("child.tcpNoDelay", true);
        gServerBootstrap.bind(new InetSocketAddress(GProperties.getIntProperty("server.port", 7679)));

Что вы можете предложить для этой конфигурации?

Ответы [ 3 ]

6 голосов
/ 29 декабря 2011

Потоки Netty Boss используются только для настройки соединения, рабочие потоки используются для запуска NioWorker (не блокирует чтение / запись) или OioWorker (блокирует чтение / запись).

Если у вас есть обработчик выполнения, рабочий поток отправит событие сообщения в OrderedMemoryAwareThreadPoolExecutor.

1) Увеличение количества рабочих потоков Netty I / O до количества процессоров * 2 не поможет. Если вы используете поэтапных исполнителей, наличие более одного поэтапного обработчика выполнения для задач, не связанных с вводом-выводом, может увеличить задержку.

Примечание. Лучше установить собственную реализацию ObjectSizeEstimator в OMTPE. конструктор, потому что много циклов ЦП тратится на вычисление используемой памяти канала.

2) Есть некоторые другие параметры Netty, которые вы можете попробовать 

   //setting buffer size can improve I/O
   bootstrap.setOption("child.sendBufferSize", 1048576);
   bootstrap.setOption("child.receiveBufferSize", 1048576); 

   // better to have an receive buffer predictor 
   bootstrap.setOption("receiveBufferSizePredictorFactory", new AdaptiveReceiveBufferSizePredictorFactory(MIN_PACKET_SIZE, INITIAL_PACKET_SIZE, MAX_PACKET_SIZE))  

   //if the server is sending 1000 messages per sec, optimum write buffer water marks will
   //prevent unnecessary throttling, Check NioSocketChannelConfig doc   
   bootstrap.setOption("writeBufferLowWaterMark", 32 * 1024);
   bootstrap.setOption("writeBufferHighWaterMark", 64 * 1024);

3) Это должен быть bootstrap.setOption ("child.tcpNoDelay", true) для начальной загрузки сервера.

Существует экспериментальный скрытый параметр:

Netty NioWorker использует SelectorUtil.select для ожидания событий селектора, время ожидания жестко задано в SelectorUtil, 

selector.select(500);

установка небольшого значения дала лучшую производительность в реализации транспорта netty sctp. Не уверен насчет TCP.

1 голос
/ 28 декабря 2011

Q1) Все добавляет задержки. Netty довольно эффективен, поэтому я был бы удивлен, если задержка слишком высока для 95% + вариантов использования

Q2) Прежде чем начать беспокоиться об этом, проверьте сами производительность и определите, является ли это проблемой (задержкой или пропускной способностью).

Q3) Эта опция может помочь. Это не должно сделать это хуже. Многие современные ОС настраиваются довольно хорошо, и я не считаю, что это так важно, как раньше.

Можете ли вы уточнить, какую задержку вы пытаетесь достичь, потому что она может иметь большое значение для вашего дизайна? Это 10 мс, 1 мс, 100 с нами, 10 с нами?

0 голосов
/ 28 декабря 2011

1) Мне интересно, может ли быть задержка из-за netty (из-за отсутствия конфигурации и т. Д.) При передаче запроса от потока босса в рабочий поток?Я думаю, что здесь много, если есть задержка.Потоки находятся в пуле, им просто нужно дать работу.

ВОПРОС 2) Есть ли какие-то другие параметры, важные моменты, о которых я должен знать, чтобы добиться наилучшей производительности?Я провел кучу тестов и в итоге использовал количество потоков, которое было около 16 * от числа физических процессоров на коробке.Я пробовал номера нитей до нескольких тысяч, но когда их действительно сильно ударили, они закончили работу в GC.

ВОПРОС 3) bootstrap.setOption ("tcpNoDelay", true) ;.Есть ли недостатки в настройке этого параметра?Учитывая, что время доставки очень важно.

Определенно установите это.

...