I tend to agree with Jitu that the task may not seem as simple as one
might think. That said,
I do think it would be good if we can optimize this but it should be a
low priority task after
we get past JavaOne time frame.
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
>
>
>
--
- Doug