Tatu Saloranta wrote:
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).
I know, my web proxy is aimed at speeding up slow
connections, that means modem pools and similar things.
The old version did use one thread per client and it
had problems with many (not sure exactly > 1000) clients.
The newer, nio based, versions seems better.
Considering that modem users are very slow nio seems very good.
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
used.
I have seen client side functionality, but that may be an exception
since I did write it myself...
You can look at my web proxy, rabbit it does this.
http://www.khelekore.org/rabbit/
Since it is a web proxy it handles both client and server side.
It does not do http they way HttpClient does it, it is
on a lower level, but it may still be an interesting thing
to look at.
Think of a case where you have to serve 1000 requests
per second, ...
I have done that already, see above.. :-)
/robo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
