Bjarne, Can you send the a patch (diff -u) against HTTPCLIENT_2_0 branch or just a snippet of the offending code? It will help me avoid manual comparison of two files
Oleg On Wed, 2004-09-29 at 21:33, Bjarne Rasmussen wrote: > We've tried out the nightly and think there may be an issue in the > mark/reset code of > org.apache.commons.httpclient.ContentLengthInputStream.java (please see > attached for rudimentary fix). With this fix performance and > functionality is great. > > Thanks, > Bjarne. > > >>> [EMAIL PROTECTED] 9/28/2004 11:52:56 AM >>> > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
