> I just don't see how apples to apples, on a single core, blocking can be faster than NIO. Well, select() and poll() both require scanning all watched fd's, s

> I just don't see how apples to apples, on a single core, blocking can be faster than NIO. Well, select() and poll() both require scanning all watched fd's, so I could definitely see them being slow. Then if NIO is built on one of them, it would inherit that slowness. epoll doesn't need to be slow, so I'm not entirely sure what's going on there. Maybe it's only servicing one or two fd's per epoll_wait()? Maybe it has to do extra work to match an event to a Java object? Maybe queuing events for the next epoll_wait() is for some bizarre reason slower than switching threads (which I imagine is a lot lighter than a full context switch to another process)? > I think C would be a better testing ground, where you don't have built up layers over the years that reinforce one over the other. That depends on whether you're trying to benchmark the kernel or trying to figure out what will make your particular server (presumably written in Java in this case) run faster.