jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Counting actual input size [was: svn commit: r1088435]
Date Thu, 14 Apr 2011 11:14:57 GMT
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 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


Mime
View raw message