jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bennett McElwee" <>
Subject RE: Single thread making concurrent requests?!
Date Wed, 14 Jun 2006 00:27:35 GMT
I started this "concurrent requests" thread a while ago. I have just
created a separate bug report in Bugzilla, and it just occurred to me
that the bug would explain the "concurrent requests" problem too.

ASF Bugzilla Bug 39808 "Invalid redirect causes incorrect sample time"
points out that if a server returns a redirect to an invalid URL, then
JMeter erroneously doubles the time for that sample. In my case, here's
what happens:

1. JMeter sends a request to the server.
2. The server queues the request.
3. After 3 minutes, the server (under load) gives up and tries to
redirect to an error page. Sadly, due to misconfiguration, it redirects
to the invalid URL "http://HOST:PORT/error.html"
4. JMeter gets the redirect and records the time as 3 minutes.
5. JMeter tries to parse the redirect URL and creates an error result
(time: 3 minutes) since the URL is invalid.
6. Here's the bug: JMeter somehow includes the error result twice in the
overall result. It adds up the times, so the final result shows as 6
minutes even though it should be only 3.
7. My test reports go haywire.

Since affected samples will appear to have started earlier that they
actually did, this would create the appearance of overlapping samples.
I'm pretty sure that's what happened here. As sebb suspected, the
problem was with the sample durations, not the sample end times.

So we will have a nice feeling of closure on this problem once Bug 39808
is fixed. Hooray!

Bennett McElwee

-----Original Message-----
From: sebb [] 
Sent: Wednesday, 10 May 2006 11:35 pm
To: JMeter Users List
Subject: Re: Single thread making concurrent requests?!

On 09/05/06, sebb <> wrote:
> On 09/05/06, Bennett McElwee <> wrote:
> > Here's the correct calculation:
> >
> > Req 1: end 1147052818441, time 360118, so start 1147052458323
> > Req 2: end 1147052854550, time  72124, so start 1147052782426
> >
> > And note that 1147052782426 < 1147052818441. In other words, req 2
> > is (considerably) earlier than req 1 end, which should be
> >
> > Thanks for looking into it.
> The end sample times (in the CSV you sent me) are all in sequence,
> which suggests that they are probably correct.
> I think there can sometimes be a certain amount of overlap, e.g. if
> the sampler does some tidying up after completing the sample, it may
> be released to the listener a bit out of sequence. But that is not
> happening here.
> So it looks as though the sample elapsed time may be suspect. In both
> cases, the sample failed. Maybe there is a problem with the way the
> timestamps are handled in the Exception cases. I need to take a look
> again later.

Could not find anything obvious.

Are you using "follow redirects" or "download embedded resources" ?

This communication, including any attachments, is confidential. If you are not the intended
recipient, you should not read it - please contact me immediately, destroy it, and do not
copy or use any part of this communication or disclose anything about it. Thank you. Please
note that this communication does not designate an information system for the purposes of
the Electronic Transactions Act 2002.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message