Re: Counting actual input size [was: svn commit: r1088435]
On 14 April 2011 00:12, sebb wrote: > On 13 April 2011 23:33, Milamber wrote: >> >> >> Le 13/04/2011 14:26, sebb a ecrit : >>> On 13 April 2011 07:53, Milamber 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 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 wrote: > On 14 April 2011 14:14, Peter Lynch 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: nightlies vs release: two files
On 14 April 2011 16:14, Peter Lynch wrote: > 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? Because the 3rd party jars rarely change, and at the time this was set up, broadband was not generally available. Nightlies are intended for developers only; it's convenient not to have to download everything each time. > -Peter > > > On Thu, Apr 14, 2011 at 9:24 AM, sebb wrote: > >> On 14 April 2011 14:14, Peter Lynch 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 > - 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
Plus, if you're mobile, connection could be slow Sent from my iPhone On Apr 14, 2011, at 8:41 AM, sebb wrote: > On 14 April 2011 16:14, Peter Lynch wrote: >> 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? > > Because the 3rd party jars rarely change, and at the time this was set > up, broadband was not generally available. > > Nightlies are intended for developers only; it's convenient not to > have to download everything each time. > >> -Peter >> >> >> On Thu, Apr 14, 2011 at 9:24 AM, sebb wrote: >> >>> On 14 April 2011 14:14, Peter Lynch 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 >> > > - > 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
Re: Counting actual input size [was: svn commit: r1088435]
Le 14/04/2011 12:14, sebb a ecrit : > On 14 April 2011 00:12, sebb wrote: > >> On 13 April 2011 23:33, Milamber wrote: >> >>> >>> Le 13/04/2011 14:26, sebb a ecrit : >>> On 13 April 2011 07:53, Milamber 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-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
Re: Counting actual input size [was: svn commit: r1088435]
On 14 April 2011 22:09, Milamber wrote: > > > Le 14/04/2011 12:14, sebb a ecrit : >> On 14 April 2011 00:12, sebb wrote: >> >>> On 13 April 2011 23:33, Milamber wrote: >>> Le 13/04/2011 14:26, sebb a ecrit : > On 13 April 2011 07:53, Milamber 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
