On 14 April 2011 00:12, sebb <[email protected]> wrote: > On 13 April 2011 23:33, Milamber <[email protected]> wrote: >> >> >> Le 13/04/2011 14:26, sebb a ecrit : >>> On 13 April 2011 07:53, Milamber <[email protected]> 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 all the fixes to the other code. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
