Re: Counting actual input size [was: svn commit: r1088435]

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/

> Milamber
>>
>>> Thanks for all the fixes to the other code.
>>>
>> ---------------------------------------------------------------------
>> 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]
>
>