Perhaps there is a workaround for this, but I have identified a small flaw in how JMeter is running threads.
Assume for a second that I have a test where I want to run a 100 simultaneous users through a procedure. I'd like the test to start and finish running 100 simultaneous threads. The way JMeter runs threads, it pre-divides the number of iterations among the 100 threads - so if you are going to run 1000 loops, each thread will get 1000 iterations to run through. Normally, you'd think this was OK... Since each thread will do 1000 loops, on 'average' they will work out to do the same amount of work. But in practice, threads complete their 1000 loops at different intervals, so that by the time the test completes - only a few threads were still running at the very end. When you are trying to measure performance under load, this skews your result - because the last few iterations occur with almost none of the intended load. This means the last few threads execute very quickly compared to threads operating while under 100 simultaneous requests - so the reported data shows the last few threads having a significant impact on the overall performance of the test. What I need is a test thread group that runs 'n' simultaneous threads from beginning to end - and runs until 'n' _total_ iterations are complete, instead of just 'n' per thread. Is there a thread group that works like that? -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
