Thank you for the suggestion. I'll write to him.
Scott Oaks wrote:
> I'd suggest talking to Akara Sucharitakul, who has developed lots of
> HTTP-client stuff for the JES-related client drivers (not to mention
> SPECjAppServer). He has some pretty lightweight HTTP client code.
>
> -Scott
>
> On Fri, 2006-02-03 at 13:48, Jitendra Kotamraju wrote:
>> Kohsuke Kawaguchi wrote:
>>
>> > 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?
>>
>> It is a lot fun as I wrote an HttpServer with CGI support and HTTP
>> keep-alive. But I think we shouldn't write our own HttpURLConnection.
>> Interoperability with different HTTP servers is a big thing(also one
>> need to support HTTP 1.0 and 1.1). Cookie management is one more
>> thing(JDK 6 gives more support). Reuse, and multiplex on underlying
>> sockets is one more thing. Also some of the Headers are really
>> necessary. We will be unnecessarily spending time in this code.
>>
>> Jitu
>>
>> >
>> > [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