[java] When does Netty's native transport make sense?

[Ryan Michela]

Does anybody have any information on when it makes sense to switch from Netty's NIO transport to the native epoll transport?

Is there some crossover where one makes sense over the other?

[Ryan Michela]

I found the following for epoll, but I'm not sure how directly it translates to gRPC.

Therefore you should only use epoll if all following is true:

• * Your application runs a thread poll which handles many network connections by a handful of threads. You would lose most of epoll benefits in a single-threaded application, and most likely it won’t outperform poll.

• * You expect to have a reasonably large number of sockets to monitor (at least 1,000); with a smaller number epoll is not likely to have any performance benefits over poll and may actually worse the performance;

• * Your connections are relatively long-lived; as stated above epoll will be slower than poll in a situation when a new connection sends a few bytes of data and immediately disconnects because of extra system call required to add the descriptor into epoll set;

• * Your app depends on other Linux-specific features (so in case portability question would suddenly pop up, epoll wouldn’t be the only roadblock), or you can provide wrappers for other supported systems. In the last case you should strongly consider libevent.

https://www.ulduzsoft.com/2014/01/select-poll-epoll-practical-difference-for-system-architects/

[Spencer Fang]

+carl

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/b2b1250e-89e3-45bd-a1a5-5709913c51ff%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Spencer Fang

[Carl Mastrangelo]

As described in that article, there are cases where the Netty native transport doesn't ad much value.  However, when you do need it, you really do need it.  The easiest cases you need it are when you are handling 100K+ connections on a single machine, or need to use Unix Domain Sockets.

If not those cases, it still is slightly better than the default poller.   OpenJDK uses epoll, but not in edge triggered mode like Netty.  When handling lots of network events at a time, Netty may wish to not get notified of each one.  For example, if you have lots of sockets in your pollset, many of them may become writable or readable.  If your application is not ready to read or write though, then being woken up each time you poll is wasteful.  You *could* remove the fd from the pollset in such a case, but that would be expensive in terms of JNI calls.  

Also, the JDK creates a fair amount of garbage when polling.  The native transport avoids garbage creation. 

As for how it applies to gRPC?  I think the two main benefits are the high connection count and low garbage creation.  gRPC Java uses a single thread for each connection (though threads may have multiple connections).  This means that effectively gRPC is single threaded at that point.  The article is right though, most of the reasons to use epoll are for more exotic threading schemes.