[concurrency-interest] Blocking vs. non-blocking

Oleksandr Otenko oleksandr.otenko at oracle.com
Tue Aug 5 10:12:32 EDT 2014

That still leaves everyone wonder why one would prefer to code in 
continuation-passing style compared to straightforward blocking IO. Both 
IO being on par is not reason enough to switch.


On 03/08/2014 20:06, Zhong Yu wrote:
>> 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
> bayou.io
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list