Kohsuke Kawaguchi wrote:
> I still can't even install Glassfish because the installer doesn't
> respond --- guess I can't complain since I wrote it :-(
OK, I got it working by using JDK 1.4. The installer needs to be
rewritten anyway, to get rid of this ridiculous -Xmx256m requirement.
I run this with a profiler and I got the attached result. When running
inside a profiler, it reduces the relative weight of the server time and
the network time, so you can clearly see that the new architecture is
willing a big time. It more than doubles the throughput (831 vs 1756) [1].
But yet, if I run this outside the profiler, I get a marginal 15%
improvement or so.
A part of the reason for this must be that this test only sends/receives
a tiny message (and therefore increases the relative weight of network.)
But I think it's clear that we can boost the number considerably if we
think about the network interfacing more carefully.
For example, JDK HttpUrlConnection class sends out a lot of headers [3],
like "User-Agent" or cache control headers and so on, and it also
spends a lot of time parsing headers that we'll never even care. So
there's a room of improvement here.
Similarly, since we'll most likely be sending the same set of headers
multiple times, it makes sense to actually encode them to byte[]
eagerly, so that we can just write most of the headers with a single
OutputStream.write().
I also suspected the latency in establishing TCP connection, but it
turns out that HTTP Keep Alive worked for this benchmark and therefore
there was virtually no connection overhead.
So I'm almost wondering if we can write a simple HTTP client library
dedicated for WebService,
- it should only send out headers that are absolutely necessary
- it doesn't have to support all the HTTP complexity, like
authentication, proxy, etc. The caller can revert to JDK if
these things are needed
- it should pre-encode all headers to ASCII so that making similar
requests can be done a lot quickly.
- it shouldn't parse response headers that we aren't interested in.
- it should support HTTP keep-alive
- it should support chunked content encoding
It's probably a non-trivial task, but I think it's a lot of fun. And if
done well, I think it can marginalize the performance benefit of TCP
binding (and say if you only get 10% boost by switching to the custom
TCP binding, I suspect a lot of people would just stick to HTTP.)
In any case, what do people think?
[1] see attached oldarch-vs-newarch.zip
[2] see attached full-speed.zip
[3] see attached parsing-headers.zip
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com