[concurrency-interest] Blocking vs. non-blocking
zhong.j.yu at gmail.com
Tue Aug 5 13:10:33 EDT 2014
On Tue, Aug 5, 2014 at 9:40 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 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
I forgot to emphasize that my test was for a single, half-duplex
connection, designed to compare how much self-time each server impl
spends on a request-response cycle.
> 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:
> 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.
>> On 03/08/2014 20:06, Zhong Yu wrote:
>>>> Also, apparently, in heavy I/O scenarios, you may have a much better
>>>> 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
>>>> 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:
>>> 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 . 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).
>>>  http://bayou.io/draft/Comparing_Java_HTTP_Servers_Latencies.html
>>> Zhong Yu
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> - DML
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest