[concurrency-interest] Blocking vs. non-blocking

Zhong Yu zhong.j.yu at gmail.com
Sun Aug 3 15:06:28 EDT 2014

> Also, apparently, in heavy I/O scenarios, you may have a much better system
> throughput waiting for things to happen in I/O (blocking I/O) vs being
> notified of I/O events (Selector-based I/O):
> http://www.mailinator.com/tymaPaulMultithreaded.pdf. Paper is 6 years old
> and kernel/Java realities might have changed, YMMV, but the difference
> is(was?) impressive. Also, Apache HTTP Client still swears by blocking I/O
> vs non-blocking one in terms of efficiency:
> http://wiki.apache.org/HttpComponents/HttpClient3vsHttpClient4vsHttpCore

To add a small data point to this discussion, Tomcat with NIO is
apparently slower than Tomcat with Blocking-IO by 1,700ns for a simple
request-response, according to a benchmark I did recently [1]. But!
The difference is very small, and I would argue that it is negligible.

Paul Tyma's claim (that the throughput of Blocking-IO is 30% more than
NIO) is not very meaningful for real applications. I did once
replicate his claim with a test that does nothing with the bytes being
transferred; but as soon as you at least read each byte once, the
throughput difference becomes very unimpressive (and frankly I suspect
it's largely due to Java's implementation of NIO).

[1] http://bayou.io/draft/Comparing_Java_HTTP_Servers_Latencies.html

Zhong Yu

More information about the Concurrency-interest mailing list