[concurrency-interest] Blocking vs. non-blocking

Stanimir Simeonoff stanimir at riflexo.com
Tue Aug 5 19:31:35 EDT 2014


On Tue, Aug 5, 2014 at 5:12 PM, Oleksandr Otenko <
oleksandr.otenko at oracle.com> 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.
>
> With thousands of persistent full duplex connections the non-blocking IO
offers better latency and control under load...or at least that's my
experience in server workloads.

Tomcat is not a good example of good NIO code and features some doubtful
choices like using CLQ for small object caches (the CLQ node being larger
than the cached object), so I'd leave it at that.

Stanimir



> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140806/edcf670d/attachment.html>


More information about the Concurrency-interest mailing list