Couple of things: 1) Recent versions of the 1.6 JDK will use epoll on Linux. Thus the benchmark should be re-evaluated. poll() is known to not very scalable. T

Couple of things: 1) Recent versions of the 1.6 JDK will use epoll on Linux. Thus the benchmark should be re-evaluated. poll() is known to not very scalable. There is an issue, however: NIO only supports level triggered (not edge triggered) epoll. 2) This doesn't cover the case of threadpool starvation. I.e., there are multiple connections, some are very fast, some are very slow. Prime example of this would be a client for a WAN-distributed database or a WAN-distributed file system: most operations are local (5 ms), some operations are remote (80 ms). Remotes are lingering longer and longer in a fixed size threadpool, leaving less and less space in the threadpool causing a longer wait time for incoming operations. You can even have this without WAN distribution e.g., 80% of operations require no random disk seeks (are retrieved from cache), 20% require them (orders of magnitude slower operation even with elevator scheduling).