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

2
votes

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
javamultithreadingnetty
Ideally, you should not have any blocking code in your application. If you want to handle many simultaneous actions, a huge pool of threads will cause you lots of performance problems in the long run and opens up the possibility of a catastrophic failure when you hit some theoretical limitation. - Johnny V
@JohnnyV at some point there will be a blocking operation in an application that needs DB read. you can do things asynchronously but IO is blocking at some point - brain storm

1 Answers

3
votes

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.