jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Where is the correct place for a synchronizing timer?
Date Tue, 12 Aug 2014 23:40:44 GMT
One way to test the structure of a plan is to use the Java Sampler.
Choose the timeouts to approximate the actual samplers that will be
used in the real plan.
Then you can experiment with timers without having to rely on an
external server.

On 12 August 2014 20:34, Philippe Mouawad <> wrote:
> Hello,
> Could you show the structure of your plan .
> Run it with initial ramp up and check ok
> Run it with new ramp up and check ko, if ko show the errors you get
> Thanks
> On Tuesday, August 12, 2014, Pickard, Nigel <> wrote:
>> Thanks for the reply Sebb, you are right, I had some confusion about the
>> scope.  I reread the documentation -but alas am still unclear.
>> To summarize:
>> I have a thread group with a simple controller.
>> Under the simple controller I have several samplers -e.g. login, ABC and
>> XYZ
>> I'd put a synchronizing timer within XYZ with the hope of allowing login
>> and ABC to run completely with all users, and then burst to the XYZ sampler.
>> This test had seemingly run satisfactorily, until I increased the ramp up
>> time of users I'd been creating -then I was getting errors.  I then had a
>> crisis of confidence that the synchronizing timer should be at the simpler
>> controller level rather than a child of the XYZ sampler...... but I think
>> what I'd done was correct.  But now I'm uncertain as to how increasing ramp
>> up time causes a problem with a sample that has a nested synchronized timer.
>> -----Original Message-----
>> From: sebb [ <javascript:;>]
>> Sent: Monday, August 11, 2014 8:12 PM
>> To: JMeter Users List
>> Subject: Re: Where is the correct place for a synchronizing timer?
>> I've not looked at the post in detail, but would just point out that
>> Timers are executed AFTER every request that is in scope.
>> As such, it does not make sense to say that the timer is "at the top".
>> See:
>> On 11 August 2014 23:15, Pickard, Nigel <
>> <javascript:;>> wrote:
>> > I was using a synchronizing timer to best mimic a burst of http
>> requests..... however, running a test I came across an anomaly that made me
>> think I'm doing it incorrectly.
>> >
>> > I had a http request to login in users (call it "Login"), then another
>> http request that got something from my web site (call it "ABC"), then
>> another request (the one I'm most interested in -which I'll call "XYZ"
>> -where all users are instantaneously forwarded to another site).  I had the
>> number of users and a ramp up time to accommodate for the users to be
>> logged in and to do "ABC".  I put a synchronizing timer inside the http
>> request "XYZ" -at the top -within the request.   My thought was that users
>> would log in, do "ABC" in good time, then "XYZ" would wait until all users
>> had logged in and done "ABC", and then all users would attempt the sudden
>> burst of "XYZ".
>> >
>> > I'd run my load tests with no trouble -or so I thought.    Then the
>> other day I happened to extend the ramp up time and mysteriously "XYZ"
>> started to fail.   It seems counter intuitive; why would providing a longer
>> ramp up time (and well within any timeouts as well, we're talking 30 secs
>> as a ramp up time here instead of 20 seconds) cause failure?
>> >
>> > I then realized moving the synchronizing timer between http requests
>> would allow for success, rather than leaving it inside (at the top) of the
>> "Xyz" request.  I've searched (a lot) of JMeter tutorials and I can't find
>> clarification on this -should the synchronizing timer be outside the http
>> request, and before the request you wish to have a "burst" on?  Scratching
>> my head on this.... Thanks.
>> >
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: <javascript:;>
>> For additional commands, e-mail:
>> <javascript:;>
> --
> Cordialement.
> Philippe Mouawad.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message