On 15 April 2011 08:21, Milamber <[email protected]> wrote: > > > Le 14/04/2011 23:09, sebb a ecrit : >> On 14 April 2011 22:09, Milamber <[email protected]> wrote: >> >>> >>> Le 14/04/2011 12:14, sebb a ecrit : >>> >>>> 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 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?
I don't see the behaviour you are reporting; HC4 seems to work OK for me with the snapshot build. Did you remove/rename the existing httpcore jar? What URL are you seeing the problem with? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
