由于将请求从主线程传递到工作线程,netty 中出现延迟?
我有一些关于 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)));
您对此配置有何建议?
I have some questions about Netty (Server Side), TCP/IP applications;
I am wondering if there can be latency because of netty (due to missing configuration etc.) while passing the request from boss thread to worker thread ?
I am using :
new OrderedMemoryAwareThreadPoolExecutor(350, 0, 0, 1, TimeUnit.SECONDS);
Actually, I set max thread count 350
as I am not sure about the optimal number. I log simultaneous working thread count every minute and it seems that average is too low (barely exceeds 10
). So I will decrease this number as it is not required.
Is there any other parameters,important points that I should be aware of for to get best performance ?
bootstrap.setOption("tcpNoDelay", true);
- Is there any disadvantage of setting this parameter? Considering that delivery time is very important.
Thread Pool Executer:
OrderedMemoryAwareThreadPoolExecutor executor = new OrderedMemoryAwareThreadPoolExecutor(48, 0, 0, 1, TimeUnit.SECONDS);
Here is my pipeline factory:
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());
and the 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)));
What can you suggest for this configuration ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
Netty Boss线程仅用于建立连接,工作线程用于运行NioWorker(非阻塞读/写)或OioWorker(阻塞读/写)。
如果您有执行处理程序,工作线程会将消息事件提交给 OrderedMemoryAwareThreadPoolExecutor。
1) 将 Netty I/O 工作线程数增加到超过处理器数量 * 2 不会有帮助。如果您正在使用分阶段执行程序,则为非 I/O 任务拥有多个分阶段执行处理程序可能会增加延迟。
注意:最好在 OMTPE 中设置自己的 ObjectSizeEstimator 实现
构造函数,因为许多 CPU 周期花费在计算已使用的通道内存上。
2) 还有一些其他的 Netty 参数你可以尝试
3) 对于服务器引导应该是 bootstrap.setOption("child.tcpNoDelay", true) 。
有一个实验性的隐藏参数:
Netty NioWorker 使用 SelectorUtil.select 来等待选择器事件,等待时间是硬编码在 SelectorUtil 中,
设置一个较小的值可以在 netty sctp 传输实现中提供更好的性能。不确定 TCP。
Netty Boss threads are only used to setup connection, worker threads are used to run NioWorker (non blocking read/write) or OioWorker (blocking read/write).
If you have an execution handler, worker thread will submit the message event to OrderedMemoryAwareThreadPoolExecutor.
1) Increasing the Netty I/O worker thread count to more than number of processors * 2 won't help. If you are using staged executors, Having more than one staged execution handler for non I/O tasks, may increase latency.
Note: Its better to set your own ObjectSizeEstimator implementation in OMTPE
constructor, because many CPU cycles are spent on calculating used channel memory.
2) There are some other Netty parameters you can try
3) It should be bootstrap.setOption("child.tcpNoDelay", true) for server bootstrap.
There is an experimental hidden parameter:
Netty NioWorker is using SelectorUtil.select to wait for selector events, the wait time is hard coded in SelectorUtil,
setting a small value gave better performance in netty sctp transport implementation. Not sure about TCP.
Q1)一切都会增加延迟。 Netty 非常高效,因此如果延迟对于 95% 以上的用例来说太高,我会感到惊讶。
Q2) 在开始担心之前,自行测试性能并确定是否存在问题(延迟或吞吐量)。
Q3) 这个选项可能有帮助。它不应该让情况变得更糟。许多现代操作系统的自调整能力非常好,我发现它不像以前那样有那么大的区别。
您能否澄清一下您想要实现的延迟是多少,因为它会对您的设计产生很大的影响?是10毫秒、1毫秒、100我们、10我们吗?
Q1) Everything adds latency. Netty is pretty efficient so I would be surprised if the latency is too high for 95%+ of use cases
Q2) Test you performance yourself and determine if it a problem, (either latency or throughput) before you start worrying about it.
Q3) This option may help. It shouldn't make it worse. Many modern OSes self tune pretty well and I don't find it makes as much difference as it used to.
Can you clarify what latency you are trying to achieve because it can make a big difference to your design? Is it 10 ms, 1 ms, 100 us, 10 us?
我认为这里没有太多延迟(如果有的话)。线程位于池中,只需为它们分配工作即可。
当谈到“最佳”性能时,我做了一系列测试,最终使用的线程数大约是盒子上物理处理器数量的 16 倍。我尝试了数千个线程数,但当它们受到真正的冲击时,它们最终会在 GC 中崩溃。
一定要这样设置。
I don't think there's much if any latency here. The threads are in a pool, they just need to be given the work.
When it comes to 'best' performance, I did a bunch of testing and ended up using a number of threads that was about 16* the number of physical processors on the box. I tried thread numbers up to several thousand, but when they got really slammed, they ended up thrashing in GC.
Definitely set this.