Synchronizing Timers buggy?

[Richard Gaywood <ri...@gmail.com>]

Hi group!

I'm experimenting with adding a synchronzing timer to my existing XML-RPC
load test (hitting on a simple web service[1]) to emulate some peak load
we're seeing on our live servers. However, the test has gone a bit wonky...
it doesn't seem to end cleanly. For example, in the test I've got running
right now, I had 80 threads with a sync timer to group them into five at a
time, with a timer on the thread group of 30 seconds. The test ended over
ten minutes ago but the JMeter UI claims "2/80" threads are still active;
I've hit "stop test" and that's wedged on "shutting down all test threads,
please be patient". "netstat -n" shows no active connections to my
webservice so it's not a socket timeout thing (been there, done that, got
the scars to prove it too :oD)

I vaguely recall reading somewhere that the synchronizing timer can have
these problems, but googling the list hasn't turned anything up. Is there
any work around?

(I'm using Sun's JDK 1.5.0 reg 09-b03 and JMeter 2.2.)

[1] simple test:
thread group
| - XML-RPC sampler
  | - size assertion
  | - save (failed) responses to file
  | - sync timer

Re: Synchronizing Timers buggy?

[Richard Gaywood <ri...@gmail.com>]

On 12/5/06, sebb <se...@gmail.com> wrote:
>
> I've not used the Sync Timer in earnest, so I don't know if it has
> these problems.


Fair enough!

I do know that sometimes the 2/80 display can go wrong (I've seen -1/n
> !), but the fact that "stop test" is having a problem suggests that
> there are indeed still some threads active.


Yeah, I've seen that -1 thing too. I've also seen some problems with the
webapp I'm testing here were threads get stuck with open ports, sometimes in
ESTABLISHED, sometimes in SYNC_WAIT or FIN_WAIT_1. Upgrading to Java5 fixed
most of these problems, although it does still occasionally bomb out when
it's been under heavy load. I haven't figured out if it's JMeter, Java, the
app, network drivers, the switch, or something even more esoteric to blame
for this fault.


[BTW, Shutdown is a less forceful version - it does not kill threads]


Ah, I'll keep that in mind.


It might be worth replacing the sampler with a Java Request Sampler
> (use a similar time delay) to see how the Sync Timer behaves with a
> simpler test.



I'll give it a go when I have five minutes.

Thanks, Seb!


S.
> On 05/12/06, Richard Gaywood <ri...@gmail.com> wrote:
> > Hi group!
> >
> > I'm experimenting with adding a synchronzing timer to my existing
> XML-RPC
> > load test (hitting on a simple web service[1]) to emulate some peak load
> > we're seeing on our live servers. However, the test has gone a bit
> wonky...
> > it doesn't seem to end cleanly. For example, in the test I've got
> running
> > right now, I had 80 threads with a sync timer to group them into five at
> a
> > time, with a timer on the thread group of 30 seconds. The test ended
> over
> > ten minutes ago but the JMeter UI claims "2/80" threads are still
> active;
> > I've hit "stop test" and that's wedged on "shutting down all test
> threads,
> > please be patient". "netstat -n" shows no active connections to my
> > webservice so it's not a socket timeout thing (been there, done that,
> got
> > the scars to prove it too :oD)
> >
> > I vaguely recall reading somewhere that the synchronizing timer can have
> > these problems, but googling the list hasn't turned anything up. Is
> there
> > any work around?
> >
> > (I'm using Sun's JDK 1.5.0 reg 09-b03 and JMeter 2.2.)
> >
> > [1] simple test:
> > thread group
> > | - XML-RPC sampler
> >  | - size assertion
> >  | - save (failed) responses to file
> >  | - sync timer
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Re: Synchronizing Timers buggy?

[sebb <se...@gmail.com>]

I've not used the Sync Timer in earnest, so I don't know if it has
these problems.

I do know that sometimes the 2/80 display can go wrong (I've seen -1/n
!), but the fact that "stop test" is having a problem suggests that
there are indeed still some threads active. [BTW, Shutdown is a less
forceful version - it does not kill threads]

It might be worth replacing the sampler with a Java Request Sampler
(use a similar time delay) to see how the Sync Timer behaves with a
simpler test.

S.
On 05/12/06, Richard Gaywood <ri...@gmail.com> wrote:
> Hi group!
>
> I'm experimenting with adding a synchronzing timer to my existing XML-RPC
> load test (hitting on a simple web service[1]) to emulate some peak load
> we're seeing on our live servers. However, the test has gone a bit wonky...
> it doesn't seem to end cleanly. For example, in the test I've got running
> right now, I had 80 threads with a sync timer to group them into five at a
> time, with a timer on the thread group of 30 seconds. The test ended over
> ten minutes ago but the JMeter UI claims "2/80" threads are still active;
> I've hit "stop test" and that's wedged on "shutting down all test threads,
> please be patient". "netstat -n" shows no active connections to my
> webservice so it's not a socket timeout thing (been there, done that, got
> the scars to prove it too :oD)
>
> I vaguely recall reading somewhere that the synchronizing timer can have
> these problems, but googling the list hasn't turned anything up. Is there
> any work around?
>
> (I'm using Sun's JDK 1.5.0 reg 09-b03 and JMeter 2.2.)
>
> [1] simple test:
> thread group
> | - XML-RPC sampler
>  | - size assertion
>  | - save (failed) responses to file
>  | - sync timer
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org