On 15 April 2011 08:21, Milamber milam...@apache.org wrote:
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?
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: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org
