The simple answer is you would never do that. You will always have a ramp-up and a ramp-down. You should exclude these phases in your calculations if you need the values under load only. Even if you "thread issue" were fixed, how would you deal with differing response times? They still affect your load.
If you use a constant throughput timer you should see less of the behavior you're describing but there will still be some. On the other hand I'm wondering what you're trying to prove. Usually a test exasperates a problem/issue and a "clean" load is not necessary. Or you're doing a baseline in wich case you're only interested in repeating the same test again. If you need stats then you can apply the suggestion above. Cheers Oliver On 13/09/11 7:02 AM, "Robin D. Wilson" <rwils...@gmail.com> wrote: >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 > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
