hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCore] NIO extensions: progress report
Date Mon, 28 Aug 2006 22:44:10 GMT
On Mon, 2006-08-28 at 13:44 -0700, Tatu Saloranta wrote:
> 
> --- Oleg Kalnichevski <olegk@apache.org> wrote:
> 
> > On Sun, 2006-08-27 at 14:18 -0700, Tatu Saloranta
> > wrote:
...
> 
> I don't see how this would solve the problem, as long
> as
> threads essentially must be used for doing blocking
> access...
> Unless I am missing something (which is possible, so
> please
> read on).
> 
> Also, I am not thinking raw performance (throughput)
> as much
> as scalability and robustness WRT number of concurrent
> open connections.
> High throughput does not help if the system crashes
> under
> high load. This is the usual "linux vs. solaris"
> comparison:
> for some cases you just want the most optimal
> solution, for
> others more robust operation (graceful degradation of
> the
> quality of service).
> 
> > more advantageous only if most of those connections
> > constantly generate
> > some fair amount of traffic at a very low rate thus
> > infinitely blocking
> > worker threads and preventing them from being
> > efficiently reused. At the
> 
> Yes, although I am not thinking of low rate so much,
> but high latency:
> if a call to another (slow) service takes 500 ms to
> respond,
> the thread in question will be idling, and you need
> huge
> number of 'worker' (idler, rather...) threads just for
> this
> simple binding. And knowing how badly Java threading
> scales
> on most platforms, at 1000 thread pool you are SOL due
> to
> scheduling overhead.
> 
> But perhaps it is possible to just decouple handling
> of the request
> sending, and response processing from each other, and
> on average blocking
> on each of those would be much less problematic, than
> that of static thread
> allocation for the whole request/response transaction.
> 
> Come to think of this now, maybe this is exactly what
> has
> been talked about so far? ;-)

Pretty much. The problem is not blocking I/O as such. The problem is the
overhead of context switching between idle threads blocked waiting on an
I/O operation. Anything that helps reduce the number of idle threads
should generally improve system scalability.

> If so, yes, you are exactly right, this might solve
> many of
> the problems of the simple thread-per-connection
> strategy.
> 
> > same time asynchronous HTTP transport may easily
> > succumb to the same
> > problem when using a dedicated worker thread per
> > HTTP request / HTTP
> > connection.
> 
> Sure. NIO is no silver bullet: obviously processing of
> request and replies also needs to get rid of the 
> one-thread-per-request strategy.
> 

If you absolutely sure you want to be able to handle multiple requests
or responses simultaneously using just one worker thread, NIO is the
only way to go.

Anyways, we want HttpCore to be as flexible and versatile as possible.
This is my primary motivator for working on the NIO extensions. All I am
saying the non-blocking I/O may not be the best strategy in all cases
and should be used selectively where appropriate. Benefits of NIO on the
client side seem lesser than on the server side. 

Cheers

Oleg

> -+ Tatu +-
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
> 


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


Mime
View raw message