On 14 April 2011 22:09, Milamber <milam...@apache.org> wrote: > > > Le 14/04/2011 12:14, sebb a ecrit : >> On 14 April 2011 00:12, sebb <seb...@gmail.com> wrote: >> >>> On 13 April 2011 23:33, Milamber <milam...@apache.org> wrote: >>> >>>> >>>> Le 13/04/2011 14:26, sebb a ecrit : >>>> >>>>> On 13 April 2011 07:53, Milamber <milam...@apache.org> wrote: >>>>> >>>>> >>>>>> I've updated the patch on bug 43363 since your last commit on HC4 >>>>>> >>>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=43363 >>>>>> >>>>>> With your last commit on HC4Impl, the header size and body size aren't >>>>>> good with a gzip stream ou chunked response. >>>>>> For example, with a chunked response, they are: >>>>>> HC4: >>>>>> Size in bytes: 8199 >>>>>> Headers size in bytes: 8192 (=> Like a buffer reader?) >>>>>> Body size in bytes: 7 >>>>>> >>>>>> Java & HC3 (good value, verified with wireshark) >>>>>> Size in bytes: 10505 >>>>>> Headers size in bytes: 581 >>>>>> Body size in bytes: 9924 >>>>>> >>>>>> >>>>>> For a gzip response: >>>>>> HC4: >>>>>> Size in bytes: 14025 (good) >>>>>> Headers size in bytes: 1440 >>>>>> Body size in bytes: 12585 >>>>>> >>>>>> Java & HC3: >>>>>> Size in bytes: 14025 >>>>>> Headers size in bytes: 291 >>>>>> Body size in bytes: 13734 >>>>>> >>>>>> It is a bug with HttpClient 4.1 too? >>>>>> >>>>>> >>>>> Possibly. >>>>> >>>>> Since starting to use the metrics I've found that they are mainly >>>>> intended for use in custom keep-alive strategies, so may not always >>>>> provide the data we want, but I'm hoping to patch HC4 to provide more >>>>> useful stats in future. >>>>> >>>>> If you can provide details of how you are generating the test data >>>>> above, I can take a further look at the problem. >>>>> >>>>> >>>> I've put a simple test case to show diff between plain/gzip/chunked >>>> response with the three http request type >>>> >>>> https://issues.apache.org/bugzilla/attachment.cgi?id=26885 >>>> >>> Thanks! >>> >>> I can see that there is definitely a problem with the HC4 counts, and >>> it's a bit odd. >>> >>> If I put a break-point just after >>> >>> long headerBytes = metrics.getReceivedBytesCount(); >>> >>> and another after >>> >>> long totalBytes = metrics.getReceivedBytesCount(); >>> >>> the headerBytes value is the same as displayed when running at full >>> speed, but the totalBytes figure is generally much higher. Weird. >>> >>> I can hopefully reproduce this directly as an HC4 test case (without >>> all the JMeter code) and use that to fix the issue. >>> >> Turned out that the fix was simple (HTTPCORE-254) - the HC4 code was >> not always updating the metrics. >> That part of the code seems to depends on how much data is available, >> so the behaviour is timing related. >> >> I still need to fix the original issue so stats can safely be obtained >> for responses with no content (e.g. HEAD) >> (though we have a work-round for JMeter). >> > > Thanks for your works on this bug. > > Where download a nightly build of httpcore for test in JMeter? > (or I must compile last trunk?)
I've created a snapshot here: https://repository.apache.org/content/repositories/snapshots/org/apache/httpcomponents/httpcore/4.1.1-SNAPSHOT/ > Milamber >> >>> Thanks for all the fixes to the other code. >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
