Le 14/04/2011 23:09, sebb a ecrit : > 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/ >
Thanks. I've tested, but don't works perfectly. With HC4, headers size always 1440 bytes. (total response size are good) Perhaps, we must calculate headears size like HC3 instead of use metrics? > >> 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
