If I don't hear any objections or ideas for other things to include in 2.0.2 I'll call for a vote in the morning. Also, it would be nice to have some specifics about the performance increase to include in the release announcement. In particular if we could say something like "2.0.2 improves the performance of most requests by 10-20%".
Mike
On Sep 28, 2004, at 11:52 AM, Oleg Kalnichevski wrote:
Great news indeed. The reported performance boost does justify cutting a
new release. Folks, how do you all feel about releasing HttpClient
2.0.2?
Oleg
On Tue, 2004-09-28 at 00:38, Eric Johnson wrote:And I've finally gotten test results back from the appropriate people here.
In our test lab, between HttpClient 2.0.1 and the nightly, we found a
difference of about 4ms per request. As this was a live-test
environment, with all of our application environment around HttpClient,
the total numbers are probably mostly irrelevant to HttpClient, but the
measurable improvement was entirely due to HttpClient changes.
We have some other statistics, but I worry that those are misleading for
now, so I'm not mentioning those. Hopefully, I'll be able to pass along
some concrete data at some point.
For our purposes, the build otherwise looks stable.
-Eric.
Oleg Kalnichevski wrote:
Folks,
Could you please grab the latest 2.0 nightly build and see if it runs
stable enough for production purposes? When we have a couple of reports
confirming adequate stability, we'll call for the 2.0.2 release
Oleg
On Fri, 2004-09-03 at 00:00, Eric Johnson wrote:
My read on Odi's statistics is that the patch has a pretty consistent
1ms impact on every request. This corresponds pretty well with my
understanding of the theoretical improvements behind the patch. To the
effect that HttpClient's performance is affected, header parsing will be
faster, and reading the body of the connection will be roughly the same,
presumably because the client of HttpClient buffers large reads.
On a 1Ghz machine, this patch means one million processor cycles that
can be put to a better use for *each* request. That's more than
benchmark optimization, I think.
-Eric.
Oleg Kalnichevski wrote:
-------------------------------------------------------------------- -Eric,
This patch makes a difference for only relatively small payloads when
the response content is about the size of the status line + headers. In
most (real life) cases the performance gain is virtually negligible.
This is more about benchmark optimization than anything else.
Yet, it see no problem with another point release
Oleg
On Thu, 2004-09-02 at 19:06, Eric Johnson wrote:
I don't know whether this would be a premature time to call for a new
release, but the prospect of significantly better performance out of
HttpClient has some people in my company very interested.
What are the chances of a 2.0.2 release with this fix in it? (I'm
willing to build from the source, but others in my company like the idea
of an "official" build perhaps more than they need to.)
-Eric.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
