I've not used it much, but the only problem I can think of with 1.6 is the change to the socket code which causes the "unconnected socket" error when using HTTPS.
[This was a bug in JMeter which has been fixed; the nightlies work with 1.6] Are there any other problems with 1.6 you know of? On 27/03/2009, Oliver Erlewein [DATACOM] <oliver.erlew...@datacom.co.nz> wrote: > Hi Noel, > > I'd stay away from using Java 1.6.0 for now. Hasn't yet proven to be > that dependable. Sebb might have some more info on that. > > Cheers Oliver > > > -----Original Message----- > From: Noel O'Brien [mailto:nobr...@newbay.com] > Sent: Friday, March 27, 2009 3:17 AM > To: jmeter-user@jakarta.apache.org > Cc: sebb > Subject: Re: Accuracy of Elapsed Time > > > On Thursday 26 March 2009 13:00:02 sebb wrote: > > On 26/03/2009, Noel O'Brien <nobr...@newbay.com> wrote: > > > Hi, > > > > > > I'm running some load testing, nothing too heavy. 10 JMeter > threads, > > > ramp up is 30. JMeter is run from the command line and the test plan > has > > > no listeners. using the -l flag, I capture the results to a CSV > file. > > > > Good. > > > > JMeter version? > > JMeter 2.3.2:r665936 > Java: Sun 1.6.0_06-b02 > OS: RHEL 5.2 running in RHEL hypervisor > > > > I then load the results file into JMeter and look at hem from a > Summary > > > Listener, View Tree Listener etc. I'm a little confused by the > elapsed > > > time results. > > > > > > The app under test has the ability to log the time that's taken to > > > receive the request and complete sending the response, which for an > auth > > > API call it lists as taking 114ms for example (ronded to the closest > ms) > > > > > > I've set up tcpdump on the machine running the app (refer to as > server > > > henceforth) and the machine running JMeter (refer to as client > > > henceforth). > > > > > > tcpdump on the server reports that the time between the request and > > > response packets to be 113.83ms, while tcpdump on the client reports > that > > > the time between the request and response packets 113.96ms > > > > > > However for that particular HTTP request, JMeter reports that the > load > > > time (elasped time) is 174ms and that the latency is 174 ms also. > How is > > > this discrepancy explained? > > > > There is overhead in the OS, Java and JMeter on both sending and > receiving. > > Some of the other API calls I make only show a difference of a few ms in > JMeter > compared to the app/tcpdump > > > Note also that the timer resolution will affect the reported elapsed > time. > > However if you are running 2.3.2+ on Java 1.5+ it will use a higher > > resolution timer. > > Does it matter that the auth API call is the first call for each thread? > (Is > the thread doing extra work at it's start-up that would impact the > time?) > > > > As I understand it, the latency is the time taken to receive the > first > > > byte of the response and since the load time and latency are the > same > > > then it indicated that the response payload was received within 1 > ms. Is > > > this correct? Or is it even possible to achieve this? The payload > size > > > for this response is 106 bytes. > > > > Latency is time to first response. > > This may be the entire response, especially for small payloads. > > Ah, I see :) > > > > From the tcpdump on the client, it's clear that the response > packets are > > > available to JMeter after 113ms (*) so I'm concerned about what's > > > causing the increase. > > > > (*) The OS (and Java) have to process the request before tcpdump sees > > it, and likewise after tcpdump sees the response. > > Hmmm, see above re: other API calls. > > > > FWIW, the auth request sampler has an XPath Extracter Post > processor, > > > but processing time for that's not included in the load time > right??. All > > > HTTP Samplers are Java, not HTTPClient. > > > > Post-Processors are not included in individual sample-times. > > Good :) > > > The HttpSampler does as little processing as possible whilst timing > > the sample, but it has to issue the connect - retrying if necessary - > > then send the data and process the response. > > > > The connection time is not currently measured separately. > > > > I don't know why the times differ by as much as you are seeing. > > Is this the case for all samples, or only a few? > > Only a few when the tests are run for a short period of time. Even with > a > single threaded test the times are off a little for some calls. > > When the test is left for more than a few hours the times seem to become > more > in-accurate. > > > And does it really matter, so long as the server can handle the load > > it's supposed to? > > Part of our tests are to test how many "users" the app can handle before > a > degradation of quality beyond a certain point (e.g. 2 seconds), so the > inaccuracies I'm seeing are not helping to determine that number :( > because > the average time per call for 10 threads grows over time > > > > Regards, > > > > > > Noel > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > > For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
