The objective of the test is to see what the system performs like when there are 100 concurrent requests going on... So long as we keep it at 100, everything is fine. When I run 10000 iterations (100 per thread), I see that about 9400-9600 into the run, my thread count begins to drop off - until I get to the last few iterations - and they seem to be with 1 or 2 threads. This means that when my test begins to wind down, the 'average' duration for the last 600 or so iterations gets progressively better and better (as the load dwindles).
I can just cut the test off at 9000 - and check the numbers there, but it would be nice to have a way to tell JMeter to cut off at 9000 (or whatever) so that I can run my tests unattended and just examine the results. Ideally, JMeter would simply have a different sort of thread group - that tried to maintain a constant number of simultaneous threads - through the end of the test, having some threads continue longer to make sure they are maintaining constant load while other threads are lagging behind in iterations. The trick here is the 'counters'... You'd want the thread group to share a universal counter - so that each iteration of a thread would pick up the next available number from the counters - otherwise you'd have an incomplete set of numbers used in your counters (e.g., a slow thread might only get through 400 of its 1000 numbers, whereas a faster thread might get through 1600 - so you'd want to make sure that the extra 600 on the fast thread were the numbers that the slower thread failed to use). (Wouldn't it be nice if I could schedule software developers like that too!) -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com -----Original Message----- From: sebb [mailto:seb...@gmail.com] Sent: Monday, September 12, 2011 2:34 PM To: JMeter Users List Subject: Re: Flaw in how JMeter runs threads... On 12 September 2011 20:15, Bruce Ide <flyingrhenqu...@gmail.com> wrote: > Could you use a synchronizing timer to insure your threads run more > consistently? I find them to be underrated, and they're worth taking a > look at if you haven't yet. But that may make the test unrealistic - are the 100 users really all doing the same thing at the same time? That's what is likely to happen. Better IMO to run a mix of requests in each thread and let the threads run at their own pace (e.g. with timers with a random element). The requests then arrive in different combinations at the server. So long as the test is run for long enough, one can either ignore or allow for the startup/shudown phase. If the test is not run for long enough, it may not be useful to show behaviour under full load. > -- > Bruce Ide > flyingrhenqu...@gmail.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
