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.
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.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
