[concurrency-interest] Blocking vs. non-blocking

Stanimir Simeonoff stanimir at riflexo.com
Tue Aug 5 19:41:32 EDT 2014


>
> There's a dilemma though - if the application code is writing bytes to
> the response body with blocking write(), isn't it tying up a thread if
> the client is slow? And if the write() is non-blocking, aren't we
> buffering up too much data? I think this problem can often be solved
> by a non-blocking write(obj) that buffers `obj` with lazy
> serialization, see "optimization technique" in
> http://bayou.io/draft/response.style.html#Response_body
>
> Zhong Yu
>

The lazy serialization unfortunately requires the object to be fully
fetched (not depending on any context or an active database connection)
which is not that different than "buffering too much" - it's just not plain
ByteBuffer (or byte[]).
Personally I don't like lazy serialization as that leaves objects in the
queues and the latter may have implications of module (classes) redeploys
with slow clients. Also it makes a lot hard quantifying the expected queue
length per connection and shutting down slow connection.

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/3b798f97/attachment-0001.html>


More information about the Concurrency-interest mailing list