Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Netty 4 performance decrease

Tags:

netty

When I upgrade from Netty 3 to Netty 4, the performance decrease is about 45%.

I compared the thread dump of Netty 3 and Netty 4 while doing performance tests. It seems the Netty 4 server used more time for the write operations. However, if I use a client based on Netty 4 with a server based on Netty 3, the performance decrease is only about 5%, so I guessed the reason is on the server side, but I can't find the reason.

Can someone give me advice?

The code can be seen at this URL: https://code.google.com/p/nfs-rpc/source/browse/#svn%2Ftrunk%2Fnfs-rpc-netty4

like image 360
bluedavy Avatar asked Nov 04 '13 08:11

bluedavy


1 Answers

Netty4 introduced a new Thread Model, maybe you should tune your code to get better performance. Here are some points from Netty Wiki, and there are more changes in netty4.

There is no well-defined thread model in 3.x although there was an attempt to fix its inconsistency in 3.5. 4.0 defines a strict thread model that helps a user write a ChannelHandler without worrying too much about thread safety.

Netty will never call a ChannelHandler's methods concurrently, unless the ChannelHandler is annotated with @Sharable. This is regardless of the type of handler methods - inbound, outbound, or life cycle event handler methods.

A user does not need to synchronize either inbound or outbound event handler methods anymore.

4.0 disallows adding a ChannelHandler more than once unless it's annotated with @Sharable.

There is always happens-before relationship between each ChannelHandler method invocations made by Netty.

A user does not need to define a volatile field to keep the state of a handler. A user can specify an EventExecutor when he or she adds a handler to a ChannelPipeline.

If specified, the handler methods of the ChannelHandler are always invoked by the specified EventExecutor.

If unspecified, the handler methods are always invoked by the EventLoop that its associated Channel is registered to.

EventExecutor and EventLoop assigned to a handler or a channel are always single-threaded.

The handler methods will always be invoked by the same thread.

If multithreaded EventExecutor or EventLoop is specified, one of the threads will be chosen first and then the chosen thread will be used until deregistration.

If two handlers in the same pipeline are assigned with different EventExecutors, they are invoked simultaneously. A user has to pay attention to thread safety if more than one handler access shared data even if the shared data is accessed only by the handlers in the same pipeline. The ChannelFutureListeners added to ChannelFuture are always invoked by the EventLoop thread assigned to the future's associated Channel.

like image 58
liuzhengyang Avatar answered Nov 16 '22 06:11

liuzhengyang