Folks,
I put together a simple benchmark in order to have a slightly better
tool for measuring performance given the fact that the focus of HttpCore
development has recently shifted towards performance tweaking. The
benchmark is far from being perfect but is still better than tweaking
things without being able to measure the impact in some, albeit
imperfect, way.
I also took liberty of adding Jetty into the mix, as it is an
indisputable leader in the embedded HTTP space, just to have a rough
idea how HttpCore fares comparatively.
http://wiki.apache.org/HttpComponents/HttpCoreBenchmark
I am seeing very interesting results, some of which I have no good
explanation for.
(1) HttpCore (blocking) appears to be 40% faster than Jetty (blocking)
when running on Linux. At same time when run on Windows the same code
appears 10% slower. I personally consider any performance difference
within 20% as insignificant. However I am quite perplexed as to why such
a drastic difference between platforms (Win Vista vs Ubuntu Linux). The
only theory I have is the cost of native method invocations on those
platforms. HttpCore appears to store less stuff on the heap and write
/read more often directly to/from the underlying network socket. This
appears to be fast on Linux, but very costly on Windows.
Anyone has got a better idea?
(2) While Jetty (blocking) is very fast, Jetty NIO performs dismally for
me, especially on Linux. HttpCore NIO appears to be 2 times faster on
Windows and 13 times faster on Linux. All my attempts at improving Jetty
NIO performance yielded no result. It can well be I am doing something
terribly wrong. I understand Jetty cannot fully leverage NIO
capabilities in order to stay compatible with the inherently blocking
Servlet 2.x API, but still.
If anyone happens to have some experience optimizing Jetty, please help
me out.
(3) Blocking I/O is always faster than NIO, even with a fairly large
number of threads.
Do feel free to take a look at the benchmark, run it locally and help me
improve it.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
