Re: svn commit: r1088442 - /jakarta/jmeter/trunk/build.xml

2011-04-03 Thread sebb
On 4 April 2011 00:39, wrote: > Author: milamber > Date: Sun Apr  3 23:39:56 2011 > New Revision: 1088442 > > URL: http://svn.apache.org/viewvc?rev=1088442&view=rev > Log: > Add HTTPClient 4 jars libraries for the binary distribution Well spotted! > Modified: >    jakarta/jmeter/trunk/build.xml

Re: svn commit: r1088435 - in /jakarta/jmeter/trunk: bin/ src/core/org/apache/jmeter/util/ src/protocol/http/org/apache/jmeter/protocol/http/sampler/ xdocs/ xdocs/usermanual/

2011-04-03 Thread sebb
On 4 April 2011 00:13, wrote: > Author: milamber > Date: Sun Apr  3 23:13:09 2011 > New Revision: 1088435 > > URL: http://svn.apache.org/viewvc?rev=1088435&view=rev > Log: > Bug 50170 - Bytes reported by http sampler is after GUnZip > Add an optional property to allow change the method to get res

Re: [JMeter] HTTP Sampler consolidation of implementations

2011-04-03 Thread Milamber
Hello, Currently I works to add a optional property to get response size (in bytes) by different methods: 1/ default (responses data size (uncompressed length if gzip) 2/ responses headers length + default (response data size) 2/ responses headers length + content-length value (real size if gzip)

Re: [JMeter] JUnit sampler sample time changes

2011-04-03 Thread Ben Cuthbert
Thanks Sebb. This is what I have done created a new field in the file log that contains nanoSeconds and reported from the sampler is the user selects it. Ben On 3 Apr 2011, at 10:28, sebb wrote: > On 3 April 2011 08:32, Ben Cuthbert wrote: >> I see the nanotime. But the time in the sampler resu

Re: [JMeter] JUnit sampler sample time changes

2011-04-03 Thread Peter Lin
I've talked with BEA's JRockit team in the past regarding the differences in Nano time on different platforms. Given these issues, using nano time in JMeter is difficult at best. >From what I am told by Henrik stahl, making nano time reliable and performant isn't trivial, so using it to measure pe

Re: [JMeter] JUnit sampler sample time changes

2011-04-03 Thread sebb
That reminds me - Tests I've done on Windows show that nanoTime() drifts considerably when compared with currentTimeMillis(), i.e. its clock does not appear to run at the same rate. Here's a simple test you can run: public class NanoDrift { public static void main(String[] args) throws Inter

Re: [JMeter] JUnit sampler sample time changes

2011-04-03 Thread Peter Lin
Another important thing to consider is that nano time costs a lot more than System.currentTimeMillis(). I've done some benchmarking in the past and nano time costs 30% on windows. On linux, the cost is higher due to differences in how it's implemented. On Sun, Apr 3, 2011 at 5:28 AM, sebb wrote:

Bug report for Regexp [2011/04/03]

2011-04-03 Thread bugzilla
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Bug report for JMeter [2011/04/03]

2011-04-03 Thread bugzilla
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Re: [JMeter] JUnit sampler sample time changes

2011-04-03 Thread sebb
On 3 April 2011 08:32, Ben Cuthbert wrote: > I see the nanotime. But the time in the sampler results is reported in ms. So > when you have you data > it just says 0. I would like it to go one further and report a low level. Sorry, that's not possible currently. Changing the elapsed time to nano

Re: [JMeter] JUnit sampler sample time changes

2011-04-03 Thread Ben Cuthbert
I see the nanotime. But the time in the sampler results is reported in ms. So when you have you data it just says 0. I would like it to go one further and report a low level. Regards On 2 Apr 2011, at 16:18, sebb wrote: > On 31 March 2011 19:41, Ben Cuthbert wrote: >> All >> >> I have been lo