[concurrency-interest] Blocking vs. non-blocking

David M. Lloyd david.lloyd at redhat.com
Tue Aug 5 10:40:13 EDT 2014


I don't have updated benchmarks, but we researched this extensively and 
found that for server applications, and with clean, optimized 
implementations, non-blocking I/O has a large advantave, especially with 
1,000s+ connections and even with blocking workers (i.e. servlets). 
Tomcat is (please forgive me for saying it) not really a good example of 
*anything* beyond "how people used to code back in 1999".

Take this with a BIG grain of salt, but this might give you an idea as 
to the relative performance status quo of various approaches and 
languages in terms of I/O:

http://www.techempower.com/benchmarks/

Relying on papers from a decade ago, and software from even longer ago, 
is probably even less useful than one might expect.  CPU architectures, 
kernels, Java itself, and the knowledge and experience of those writing 
Java software, have come a very, very long way since then.

On 08/05/2014 09:12 AM, Oleksandr Otenko wrote:
> 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.
>
> Alex
>
> 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
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-- 
- DML


More information about the Concurrency-interest mailing list