Is it better to increase the number of worker threads or create my own thread pool in Netty?

问题: Let's assume our Netty server (4.1.32) responds http calls. Let's further assume it must perform certain blocking actions before incoming requests can be answered, for exam...

问题:

Let's assume our Netty server (4.1.32) responds http calls. Let's further assume it must perform certain blocking actions before incoming requests can be answered, for example, it must perform an outgoing call (using a different library here) to load external data.

Number of threads for NioEventLoopGroup with persistent connections dicusses

What happens if my messageReceived method blocks on something or takes a long time to complete?

which @Maksym responds with

You should avoid using thread blocking actions in your handlers.

It's clear there is only a limited number of worker threads. So blocking all available worker threads effectively means Netty will queue any further requests, until worker threads become available. On the other hand, moving blocking actions onto my own threads as suggested, will have performance impact for thread switching, and what will in turn be blocked by the available hardware is my own thread pool. IMHO using my own thread pool only adds another layer of complexity, but does not enhance performance. Instead, I'd rather increase the maximum number of worker threads and have Netty do the job of queuing requests.

What is the suggested practice here?


回答1:

You should use your own thread pool, period. The Netty worker threads are shared among many connections, if you block to handle one request it will hurt the others. The design assumes that your code returns quickly, if you need to block you must use a separate thread for that. The same applies if you need to perform a really expensive calculation, do it in another thread and return.

If you have done any Swing programming you can compare it to the GUI thread. If you block the GUI thread the user interface hangs and becomes unresponsive. Not good for a user interface and not for a high-performance networking application!

EDIT: just to be super clear, with classic IO one thread is typically assigned to a request and if the request blocks that is not the end of the world, if the thread pool is large enough other threads can process the other requests. With NIO you don't get a thread for your request, you get called by a thread that handles IO for many requests to process an event and you are supposed to do that as quickly as possible so that the thread can move on to the other requests. Blocking is really bad for the server.

  • 发表于 2019-02-23 17:42
  • 阅读 ( 297 )
  • 分类:sof

条评论

请先 登录 后评论
不写代码的码农
小编

篇文章

作家榜 »

  1. 小编 文章
返回顶部
部分文章转自于网络,若有侵权请联系我们删除