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/ On Wednesday, September 13, 2017 at 11:51:34 AM UTC-7, Ryan Michela wrote: > > 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? > -- 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 [email protected]. To post to this group, send email to [email protected]. 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.
