hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todor Boev <rinsv...@gmail.com>
Subject Re: Classic I/O vs NIO comparison; was Re: How to do cookies with NHttp*?
Date Sun, 14 Mar 2010 15:13:13 GMT
On 14.03.2010 16:29, Oleg Kalnichevski wrote:
> Todor Boev wrote:
>> On 13.03.2010 18:59, Oleg Kalnichevski wrote:
>>> Ken Krugler wrote:
>>>> Hi Todor,
>>>>
>>> ...
>>>
>>>> I was hoping it might be related to nio vs. threaded approaches to
>>>> HTTP handling.
>>>>
>>>> There's been a lot of debate about the value (performance, simplicity,
>>>> resource consumption) but I haven't seen much head-to-head comparison
>>>> where the rest of the implementation is roughly comparable. If you
>>>> ever get any comparison numbers, I'd love to see them.
>>>>
>>>> -- Ken
>>>>
>>> I have made a number of tests comparing HttpCore blocking vs HttpCore
>>> NIO vs Jetty blocking vs Jetty NIO. The results and the link to the
>>> source code can be found here:
>>>
>>> http://wiki.apache.org/HttpComponents/HttpCoreBenchmark
>>
>> So NIO seems to be about 2 times slower than blocking I/O. What was
>> the number
>> of concurrent connections used? Seems the benefit of NIO is not it's
>> speed but
>> simply the ability to maintain 10,000 concurrent connections at a time.
>>
> 
> The question is what is a legitimate use case for having to maintain so
> many concurrent connections? The only one I personally can think of is a
> proxy / gateway of some sort. I can cannot think of a single legitimate
> scenario where an HTTP agent would need to maintain more than a 100
> concurrent connections at most.

This same question has bothered me for the past few weeks. Given HTTP 1.1 allows
us to maintain only a few connections per remote host I can't think of a
scenario where we would not use connection pooling and blocking I/O.

> 
> Besides, modern operating systems and JVMs got pretty efficient at
> context switching. I would not be very surprised if blocking I/O
> outperformed NIO even with several thousand of concurrent connections.
> 
> NIO makes sense only when dealing with a _great_ number of _high
> latency_ connections, which most of the time stay idle waiting for a
> message to arrive.

Yup. I have used NIO in exactly this setting with a monitoring protocol that has
nothing to do with HTTP. I am starting to think the nature of HTTP makes NIO
useless for the client side. It is useful for the server side only because a
server must deal with unpredictable loads.

-- Todor

> 
> Cheers
> 
> Oleg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message