lopment
KingsIsle Entertainment, Inc.
VOICE: 512-777-1861
www.KingsIsle.com
-Original Message-
From: Oliver Erlewein [DATACOM] [mailto:oliver.erlew...@datacom.co.nz]
Sent: Monday, September 12, 2011 3:37 PM
To: JMeter Users List
Subject: Re: Flaw in how JMeter runs threads...
The simple answer
developers like that
>too!)
Aw shucks. Given up on mine. They ramp-down half way through ramp-up ;-
Cheers Oliver
>
>--
>Robin D. Wilson
>Sr. Director of Web Development
>KingsIsle Entertainment, Inc.
>VOICE: 512-777-1861
>www.KingsIsle.com
>
>
>-Origin
le.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 wrote:
> Could you use a synchronizing timer to insure your threads
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
Another idea would be to simply force stop the test using a Test
Action Sampler when any thread finishes its 1,000 iteration. This
could also help to prove if their is some sort of thread scheduling
problem here. For instance, if a single thread hits 1,000 and the
other threads are at their 30th
On 12 September 2011 20:15, Bruce Ide 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
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.
--
Bruce Ide
flyingrhenqu...@gmail.com
On 12 September 2011 20:02, Robin D. Wilson 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 st
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 JMe
9 matches
Mail list logo
