hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tatu Saloranta <cowtownco...@yahoo.com>
Subject Re: [HttpCore] NIO extensions: progress report
Date Wed, 30 Aug 2006 00:56:51 GMT

--- Robert Olofsson <robo@khelekore.org> wrote:

> Tatu Saloranta wrote:
> > True. A single worker thread probably need not be
> a
> > goal, but perhaps it's useful to have M:N mapping
> > between connections and worker threads.
> A single worker thread is very hard to have with
> current java.

Of course, I would never implement such a system


> Many people say that nio has higher overhead, I am
> not
> sure how much that is true, there is less context
> switches
> and direct buffers can give zero copy, which for
> some
> operations is very nice (http proxy again). Running

Sometimes, but quite seldom. Http proxy might be one
of few such use cases, or if one was to implement 
low-level layered protocol stacks.

> Do you have any benchmarks?

My impression on overhead is based on others'
experiences more than anythin else (have yet to hear
where _throughput_ would be significantly higher) --
my only direct experience was with a simple file
access (for bootstrapping in-memory xml-backed
database), where difference between regular IO and NIO
was almost nil.

> >> Benefits of NIO on the
> >> client side seem lesser than on the server side. 
> Depends on what you do, but most clients only keep a
> few
> connections open at once so threaded io is just as
> easy.

Just a note, this was not my comment, although I do
agree with that. But lesser != none.

> For me nio vs threaded io is more a question of
> style.
> NIO is more event based programming.

That is one aspect, but to me scalability aspects
regarding threading efficiency are more interesting.
When serving thousands of active (but not
hyperactive!) clients there will be a point where
network still allows more traffic to go through, but
the server overhead due to thread-management kills
performance, at least when using 'classic' one thread
owns the transaction paradigm (like servlet API).
> > documented at wiki pages) can lead to significant
> > improvements to scalability over existing http
> > solutions, 
> Just curious, what existing http solutions have you
> looked at?
> There are lots of threaded http solutions and a few
> that use nio.

On server-side there are multiple ones; all of which
might work (I have been following asyncWeb most
closely), but also have some problems with full
streaming operation. But it's really the client-side
functionality where I haven't seen combination where
number of worker threads can scale somewhat
independent of number of (logical) connections being
HttpClient, and even Sun's default http client code
work quite ok if you don't need to use more than
dozens of threads.

Think of a case where you have to serve 1000 requests
per second, but where each request results in 5
additional calls to other backend services (which may
call other services), resulting in end-to-end latency
in the order of seconds. While throughput would be
achievable -- after all it's just composing and
rearranging data flowing through (but not just blind
copy), the trick is in efficiently coordinating this
operation. Except for being able to serve 1k/s loads,
such systems already exist (any major ecommerce web
site, for example).

As to 1000 tps; I can already easily do almost 10k
requests per second on stock Tomcat, on a typical
blade box ("hello world" kind of web app): so it
should be achievable to get to kilo-request range even
with higher latencies, and similarly increased number
of concurrent open (but much of the time idle, at
least in one direction) connections.

-+ Tatu +-

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

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

View raw message