jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <milam...@apache.org>
Subject Re: Counting actual input size [was: svn commit: r1088435]
Date Thu, 14 Apr 2011 21:09:15 GMT


Le 14/04/2011 12:14, sebb a ecrit :
> On 14 April 2011 00:12, sebb <sebbaz@gmail.com> wrote:
>   
>> On 13 April 2011 23:33, Milamber <milamber@apache.org> wrote:
>>     
>>>
>>> Le 13/04/2011 14:26, sebb a ecrit :
>>>       
>>>> On 13 April 2011 07:53, Milamber <milamber@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?)

Milamber
>   
>> Thanks for all the fixes to the other code.
>>     
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org


Mime
View raw message