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! Cheerio, Bennett. -- Bennett McElwee -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: Wednesday, 10 May 2006 11:35 pm To: JMeter Users List Subject: Re: Single thread making concurrent requests?! On 09/05/06, sebb <[EMAIL PROTECTED]> wrote: > On 09/05/06, Bennett McElwee <[EMAIL PROTECTED]> 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 start > > is (considerably) earlier than req 1 end, which should be impossible. > > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
