Re: Counting actual input size [was: svn commit: r1088435]
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 all the fixes to the other code. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
nightlies vs release: two files
The nightlies require unzipping two files to make a usable runtime as described here http://people.apache.org/builds/jakarta-jmeter/nightly/ . Is it correct to assume that the a final release will just be one distributable? -Peter
Re: nightlies vs release: two files
On 14 April 2011 14:14, Peter Lynch pe...@peterlynch.ca wrote: The nightlies require unzipping two files to make a usable runtime as described here http://people.apache.org/builds/jakarta-jmeter/nightly/ . Is it correct to assume that the a final release will just be one distributable? Sort of. There is a binary dist and a source dist, and each is available as zip and tar.gz, so there are actually 4 archives (plus hashes and sigs). However only one binary is needed to run JMeter. Here is the download page: http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi -Peter - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
Re: nightlies vs release: two files
I'm trying to understand why the nightlies have a _bin.zip and _lib.zip instead of just a single .zip like the official 2.4 release did. I know the _lib.zip contains the third party jars and _bin.zip contains everything else - but why not a single .zip like the official release? -Peter On Thu, Apr 14, 2011 at 9:24 AM, sebb seb...@gmail.com wrote: On 14 April 2011 14:14, Peter Lynch pe...@peterlynch.ca wrote: The nightlies require unzipping two files to make a usable runtime as described here http://people.apache.org/builds/jakarta-jmeter/nightly/ . Is it correct to assume that the a final release will just be one distributable? Sort of. There is a binary dist and a source dist, and each is available as zip and tar.gz, so there are actually 4 archives (plus hashes and sigs). However only one binary is needed to run JMeter. Here is the download page: http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi -Peter - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org -- Peter Lynch http://blog.peterlynch.ca
Re: Counting actual input size [was: svn commit: r1088435]
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/ Milamber Thanks for all the fixes to the other code. - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
