Mailing-List: contact jmeter-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JMeter Users List" <jmeter-user@jakarta.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 74.125.46.29 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=gjKxE1efpx+8B+nWv3Pgh1UaoRJEWj8eqn3p7BXihsKMzbliOLLD1j7fSUPrm7zLvw
         SzF8YaBxhGZC2OScXbfRSaoQxn+Y2I7cktMcuLM1pjCvH0CIaj+plzBrgDssLm5E2q9i
         QEM85UBvUFjW2OCvzrozAoKgJo3TZqR57MhO8=
MIME-Version: 1.0
In-Reply-To: <46562C5EECFA8C47AADDF029EE11D73D0A2C25BB@dnzwgex1.datacom.co.nz>
References: <200903261229.51379.nobrien@newbay.com>
	 <25aac9fc0903260600x2316047al30e293a7696fcf64@mail.gmail.com>
	 <200903261416.50031.nobrien@newbay.com>
	 <46562C5EECFA8C47AADDF029EE11D73D0A2C25BB@dnzwgex1.datacom.co.nz>
Date: Fri, 27 Mar 2009 01:39:27 +0000
Message-ID: <25aac9fc0903261839ma417e95nc954e8e111349ba5@mail.gmail.com>
Subject: Re: Accuracy of Elapsed Time
From: sebb <sebbaz@gmail.com>
To: JMeter Users List <jmeter-user@jakarta.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.Erlewein@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:nobrien@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 <nobrien@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-unsubscribe@jakarta.apache.org
>  > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>  For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org