You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Vincent Daburon <vd...@gmail.com> on 2020/04/16 09:52:36 UTC
Add pacing feature
Hello,
For 3 years I have been using the notion of Pacing an iteration to
facilitate the modeling of the load and also because it is very practical
when we are doing loads with load steps
Pacing is to define a minimum duration for each iteration and wait until
this minimum time has elapsed before moving to the next one.
The pacing could be declare in a new Thread Group field and/or in a new
component.
The main advantage to modify the Thread Group is when an error occur and
the flow is going to the Next Iteration and before start the next iteration
will could wait the pacing time.
With a new component, you could declare a Pacing duration from the
beginning of the thread iteration at the place you want in the script tree.
Usually the Pacing component is declare at the end of the script but i
could be in the middle of the script or you could have multi Pacing
components.
The duration in the Pacing component could be understand like a minimum
time since the beginning of the iteration and the duration set in the
Pacing component.
Both solutions could be implements : add the Pacing duration in the Thread
Group and the Pacing component to set the minimum time since the beginning
of the iteration.
Regards.
Vincent DAB.
Re: Add pacing feature
Posted by Vladimir Sitnikov <si...@gmail.com>.
Image test :
[image: schema_pacing_4_iter_v3.png]
Vladimir
Re: Add pacing feature
Posted by Vladimir Sitnikov <si...@gmail.com>.
Vincent,
I'm not sure why do you call it pacing, but what you draw is exactly what
JMeter's Precise Throughput Timer is doing.
If you place the timer under a "flow control action" which is before
sampler1, then the timer would delay the theads that come to early.
Have you tried it?
Does it work for you?
Vladimir
Re: Add pacing feature
Posted by Vincent Daburon <vd...@gmail.com>.
Hi,
I complete pacing schema with 4 iterations :
1st iteration, sum of sampler durations < pacing
2sd iteration, *error *and Thread Group action : " *Start Next Thread Loop*"
3th iteration, sum of sampler durations *>* pacing
4th iteration, sum of sampler durations < pacing
https://groups.google.com/forum/#!topic/ptgram24/f2OVAIWazl8
Regards.
Vincent DAB.
Le jeu. 16 avr. 2020 à 15:30, Vincent Daburon <vd...@gmail.com> a écrit :
> Hi,
> I put images on this topic
> https://groups.google.com/forum/#!topic/ptgram24/f2OVAIWazl8
>
> Regards.
> Vincent DAB.
>
> Le jeu. 16 avr. 2020 à 14:45, Vincent Daburon <vd...@gmail.com> a
> écrit :
>
>> Hi,
>> When you make load test with load steps, the pacing is useful.
>> 1st step 50% of the load
>> 2sd step 100% of the load
>> 3thd step 150% of the load
>>
>> [image: Active_Threads_ALL_Over_Time.png]
>>
>> The pacing for an iteration is constant and the number of samplers is
>> proportional to the number of threads even with a response time degradation.
>>
>> The degradation in response times by the increase in the number of people
>> is normal but the rhythm (pacing) is always constant and therefore the
>> number of iterations per thread is constant.
>>
>> It's more easy to response to the question :
>> Does the system could accept 1000 functional actions by hour (2sd step
>> 100% load) ?
>>
>> Currently i use groovy script to compute a pacing.
>>
>> First sampler in the scenario a groovy script :
>> vars.put("V_PACING_START_ITER_MILLISEC","" + System.currentTimeMillis());
>>
>> at the end of the scenario a groovy script with a parameter
>> ${K_PACING_ITER_SEC} ex : 60 sec
>> String sPACING_ITER_SEC = args[0];
>> long lParcingIterSec = Long.parseLong(sPACING_ITER_SEC);
>> String sPACING_START_ITER_MILLISEC =
>> vars.get("V_PACING_START_ITER_MILLISEC");
>> long lStartIter = Long.parseLong(sPACING_START_ITER_MILLISEC);
>>
>> long lCurrentTime = System.currentTimeMillis();
>> long lDurationIter = lCurrentTime - lStartIter;
>>
>> long lWaitPacing = (lParcingIterSec * 1000) - lDurationIter;
>>
>> if (lWaitPacing <= 0) {
>> lWaitPacing = 0;
>> }
>> vars.put("V_PACING_ITER_WAIT", "" + lWaitPacing);
>>
>> and
>> Flow Control Action Pause with
>> pause : ${V_PACING_ITER_WAIT}
>>
>> but when an errror is detected if the thead group is configured with
>> "start nex thread loop" the pacing is not compute.
>>
>> Regards.
>> Vincent DAB.
>>
>> Le jeu. 16 avr. 2020 à 13:54, Vincent Daburon <vd...@gmail.com> a
>> écrit :
>>
>>> Hi
>>> a little schema to explain the pacing for an iteration for 1 thread
>>> The waiting time to complete the pacing is a dynamic waiting time.
>>> [image: schema_pacing_v1.png]
>>>
>>> Regards.
>>> Vincent DAB.
>>>
>>> Le jeu. 16 avr. 2020 à 13:32, Vladimir Sitnikov <
>>> sitnikov.vladimir@gmail.com> a écrit :
>>>
>>>> Philippe>- you don’t have a requirement of number of execution per
>>>> minute
>>>>
>>>> How do you compute "pacing" then? :)
>>>> I guess you almost always have something on the number of scenarios per
>>>> hour :)
>>>>
>>>> Philippe>How do you avoid a burst in the first steps (the one before
>>>> failure) of
>>>> Philippe>your scenario when errors start to happen, ie abnormal
>>>> increase of
>>>> Home
>>>> Philippe>Page calls or login process?
>>>>
>>>> If you configure Precise Throughput Timer, then it would ensure the
>>>> scenarios are not launched more often
>>>> than the configured throughput.
>>>> For instance, if you configure PTT rate == 10 per hour, then it would
>>>> not
>>>> allow threads to pass the timer more
>>>> often than 10 per hour no matter if the new iteration is caused by
>>>> error or
>>>> not.
>>>>
>>>> Philippe>If we had notion of try/finally
>>>>
>>>> That is a slightly different topic, and I agree it would be great to add
>>>> something for try-catch.
>>>>
>>>> Vladimir
>>>>
>>>
Re: Add pacing feature
Posted by Vincent Daburon <vd...@gmail.com>.
Hi,
I put images on this topic
https://groups.google.com/forum/#!topic/ptgram24/f2OVAIWazl8
Regards.
Vincent DAB.
Le jeu. 16 avr. 2020 à 14:45, Vincent Daburon <vd...@gmail.com> a écrit :
> Hi,
> When you make load test with load steps, the pacing is useful.
> 1st step 50% of the load
> 2sd step 100% of the load
> 3thd step 150% of the load
>
> [image: Active_Threads_ALL_Over_Time.png]
>
> The pacing for an iteration is constant and the number of samplers is
> proportional to the number of threads even with a response time degradation.
>
> The degradation in response times by the increase in the number of people
> is normal but the rhythm (pacing) is always constant and therefore the
> number of iterations per thread is constant.
>
> It's more easy to response to the question :
> Does the system could accept 1000 functional actions by hour (2sd step
> 100% load) ?
>
> Currently i use groovy script to compute a pacing.
>
> First sampler in the scenario a groovy script :
> vars.put("V_PACING_START_ITER_MILLISEC","" + System.currentTimeMillis());
>
> at the end of the scenario a groovy script with a parameter
> ${K_PACING_ITER_SEC} ex : 60 sec
> String sPACING_ITER_SEC = args[0];
> long lParcingIterSec = Long.parseLong(sPACING_ITER_SEC);
> String sPACING_START_ITER_MILLISEC =
> vars.get("V_PACING_START_ITER_MILLISEC");
> long lStartIter = Long.parseLong(sPACING_START_ITER_MILLISEC);
>
> long lCurrentTime = System.currentTimeMillis();
> long lDurationIter = lCurrentTime - lStartIter;
>
> long lWaitPacing = (lParcingIterSec * 1000) - lDurationIter;
>
> if (lWaitPacing <= 0) {
> lWaitPacing = 0;
> }
> vars.put("V_PACING_ITER_WAIT", "" + lWaitPacing);
>
> and
> Flow Control Action Pause with
> pause : ${V_PACING_ITER_WAIT}
>
> but when an errror is detected if the thead group is configured with
> "start nex thread loop" the pacing is not compute.
>
> Regards.
> Vincent DAB.
>
> Le jeu. 16 avr. 2020 à 13:54, Vincent Daburon <vd...@gmail.com> a
> écrit :
>
>> Hi
>> a little schema to explain the pacing for an iteration for 1 thread
>> The waiting time to complete the pacing is a dynamic waiting time.
>> [image: schema_pacing_v1.png]
>>
>> Regards.
>> Vincent DAB.
>>
>> Le jeu. 16 avr. 2020 à 13:32, Vladimir Sitnikov <
>> sitnikov.vladimir@gmail.com> a écrit :
>>
>>> Philippe>- you don’t have a requirement of number of execution per minute
>>>
>>> How do you compute "pacing" then? :)
>>> I guess you almost always have something on the number of scenarios per
>>> hour :)
>>>
>>> Philippe>How do you avoid a burst in the first steps (the one before
>>> failure) of
>>> Philippe>your scenario when errors start to happen, ie abnormal increase
>>> of
>>> Home
>>> Philippe>Page calls or login process?
>>>
>>> If you configure Precise Throughput Timer, then it would ensure the
>>> scenarios are not launched more often
>>> than the configured throughput.
>>> For instance, if you configure PTT rate == 10 per hour, then it would not
>>> allow threads to pass the timer more
>>> often than 10 per hour no matter if the new iteration is caused by error
>>> or
>>> not.
>>>
>>> Philippe>If we had notion of try/finally
>>>
>>> That is a slightly different topic, and I agree it would be great to add
>>> something for try-catch.
>>>
>>> Vladimir
>>>
>>
Re: Add pacing feature
Posted by Vincent Daburon <vd...@gmail.com>.
Hi,
When you make load test with load steps, the pacing is useful.
1st step 50% of the load
2sd step 100% of the load
3thd step 150% of the load
[image: Active_Threads_ALL_Over_Time.png]
The pacing for an iteration is constant and the number of samplers is
proportional to the number of threads even with a response time degradation.
The degradation in response times by the increase in the number of people
is normal but the rhythm (pacing) is always constant and therefore the
number of iterations per thread is constant.
It's more easy to response to the question :
Does the system could accept 1000 functional actions by hour (2sd step 100%
load) ?
Currently i use groovy script to compute a pacing.
First sampler in the scenario a groovy script :
vars.put("V_PACING_START_ITER_MILLISEC","" + System.currentTimeMillis());
at the end of the scenario a groovy script with a parameter
${K_PACING_ITER_SEC} ex : 60 sec
String sPACING_ITER_SEC = args[0];
long lParcingIterSec = Long.parseLong(sPACING_ITER_SEC);
String sPACING_START_ITER_MILLISEC =
vars.get("V_PACING_START_ITER_MILLISEC");
long lStartIter = Long.parseLong(sPACING_START_ITER_MILLISEC);
long lCurrentTime = System.currentTimeMillis();
long lDurationIter = lCurrentTime - lStartIter;
long lWaitPacing = (lParcingIterSec * 1000) - lDurationIter;
if (lWaitPacing <= 0) {
lWaitPacing = 0;
}
vars.put("V_PACING_ITER_WAIT", "" + lWaitPacing);
and
Flow Control Action Pause with
pause : ${V_PACING_ITER_WAIT}
but when an errror is detected if the thead group is configured with "start
nex thread loop" the pacing is not compute.
Regards.
Vincent DAB.
Le jeu. 16 avr. 2020 à 13:54, Vincent Daburon <vd...@gmail.com> a écrit :
> Hi
> a little schema to explain the pacing for an iteration for 1 thread
> The waiting time to complete the pacing is a dynamic waiting time.
> [image: schema_pacing_v1.png]
>
> Regards.
> Vincent DAB.
>
> Le jeu. 16 avr. 2020 à 13:32, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> a écrit :
>
>> Philippe>- you don’t have a requirement of number of execution per minute
>>
>> How do you compute "pacing" then? :)
>> I guess you almost always have something on the number of scenarios per
>> hour :)
>>
>> Philippe>How do you avoid a burst in the first steps (the one before
>> failure) of
>> Philippe>your scenario when errors start to happen, ie abnormal increase
>> of
>> Home
>> Philippe>Page calls or login process?
>>
>> If you configure Precise Throughput Timer, then it would ensure the
>> scenarios are not launched more often
>> than the configured throughput.
>> For instance, if you configure PTT rate == 10 per hour, then it would not
>> allow threads to pass the timer more
>> often than 10 per hour no matter if the new iteration is caused by error
>> or
>> not.
>>
>> Philippe>If we had notion of try/finally
>>
>> That is a slightly different topic, and I agree it would be great to add
>> something for try-catch.
>>
>> Vladimir
>>
>
Re: Add pacing feature
Posted by Vladimir Sitnikov <si...@gmail.com>.
>[image: schema_pacing_v1.png]
Unfortunately, the images are not yet enabled in this mailing list.
I've filed https://issues.apache.org/jira/browse/INFRA-20125 to fix that.
Could you please upload the image to gist.github.com or something like that
in the mean time?
Vladimir
Re: Add pacing feature
Posted by Vincent Daburon <vd...@gmail.com>.
Hi
a little schema to explain the pacing for an iteration for 1 thread
The waiting time to complete the pacing is a dynamic waiting time.
[image: schema_pacing_v1.png]
Regards.
Vincent DAB.
Le jeu. 16 avr. 2020 à 13:32, Vladimir Sitnikov <si...@gmail.com>
a écrit :
> Philippe>- you don’t have a requirement of number of execution per minute
>
> How do you compute "pacing" then? :)
> I guess you almost always have something on the number of scenarios per
> hour :)
>
> Philippe>How do you avoid a burst in the first steps (the one before
> failure) of
> Philippe>your scenario when errors start to happen, ie abnormal increase of
> Home
> Philippe>Page calls or login process?
>
> If you configure Precise Throughput Timer, then it would ensure the
> scenarios are not launched more often
> than the configured throughput.
> For instance, if you configure PTT rate == 10 per hour, then it would not
> allow threads to pass the timer more
> often than 10 per hour no matter if the new iteration is caused by error or
> not.
>
> Philippe>If we had notion of try/finally
>
> That is a slightly different topic, and I agree it would be great to add
> something for try-catch.
>
> Vladimir
>
Re: Add pacing feature
Posted by Vladimir Sitnikov <si...@gmail.com>.
Philippe>- you don’t have a requirement of number of execution per minute
How do you compute "pacing" then? :)
I guess you almost always have something on the number of scenarios per
hour :)
Philippe>How do you avoid a burst in the first steps (the one before
failure) of
Philippe>your scenario when errors start to happen, ie abnormal increase of
Home
Philippe>Page calls or login process?
If you configure Precise Throughput Timer, then it would ensure the
scenarios are not launched more often
than the configured throughput.
For instance, if you configure PTT rate == 10 per hour, then it would not
allow threads to pass the timer more
often than 10 per hour no matter if the new iteration is caused by error or
not.
Philippe>If we had notion of try/finally
That is a slightly different topic, and I agree it would be great to add
something for try-catch.
Vladimir
Re: Add pacing feature
Posted by Philippe Mouawad <ph...@gmail.com>.
See the other thread, it does not seem to work
On Sunday, April 26, 2020, Vladimir Sitnikov <si...@gmail.com>
wrote:
> >- Step 1 : X req/s
> >- Step 2 : Y req/s
> >- Step 3 : Y req/s
> >I am not sure it is feasible with PTT.
>
> It should be feasible if a variable is used in PTT throughput.
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Add pacing feature
Posted by Vladimir Sitnikov <si...@gmail.com>.
>- Step 1 : X req/s
>- Step 2 : Y req/s
>- Step 3 : Y req/s
>I am not sure it is feasible with PTT.
It should be feasible if a variable is used in PTT throughput.
Vladimir
Re: Add pacing feature
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Vladimir,
From schema that Vincent sent in another thread , I guess what is requested
here is ability to do steps:
- Step 1 : X req/s
- Step 2 : Y req/s
- Step 3 : Y req/s
I am not sure it is feasible with PTT.
Regards
On Mon, Apr 20, 2020 at 2:57 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >for compute by groovy code the pacing
>
> I'm afraid I don't follow you here.
> Can you please clarify why the current Precise Throughput Timer does not
> work for your "pacing" scenario?
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Add pacing feature
Posted by Vladimir Sitnikov <si...@gmail.com>.
>for compute by groovy code the pacing
I'm afraid I don't follow you here.
Can you please clarify why the current Precise Throughput Timer does not
work for your "pacing" scenario?
Vladimir
Re: Add pacing feature
Posted by Vincent Daburon <vd...@gmail.com>.
Hi,
>
*If we had notion of try/finally, it could be doable and solve also other
requirements like ensuring a session is disconnected even if error occurs*
Yes if we can set a module controler or test frament for the finally is
could be a good solution for logout or for compute by groovy code the pacing
try {
sampler 1 login
sampler 2 home page
}
finally {
sampler 3 logout
sampler 4 groovy compute paging
}
Normal flow :
sampler 1 login, sampler 2 home page, sampler 3 logout, sampler 4
Error on sampler 1 => goto finally test frament or module controller
sampler 1 login, sampler 3 logout, sampler 4
Error on sampler 3
sampler 1 login, sampler 2 home page, sampler 3 logout => no sampler 4 ?
Regards.
Vincent DAB.
Le jeu. 16 avr. 2020 à 13:13, Philippe Mouawad <ph...@gmail.com>
a écrit :
> Hello,
> What about following use case:
>
> - You have a number of virtual users running a scenario which is composed
> of 30 steps related through correlation of ids
> - You set thread group to Start next thread loop on error
> - you don’t have a requirement of number of execution per minute
>
> How do you avoid a burst in the first steps (the one before failure) of
> your scenario when errors start to happen, ie abnormal increase of Home
> Page calls or login process?
>
> If we had notion of try/finally, it could be doable and solve also other
> requirements like ensuring a session is disconnected even if error occurs
>
>
> Regards
>
> On Thursday, April 16, 2020, Antonio Gomes Rodrigues <ra...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Pacing is used in Neoload, Loadruner...
> >
> > But I am agree with Vladimir, we can use "Precise Throughput Timer" and
> > "Constant Throughput Timer"
> >
> >
> > Le jeu. 16 avr. 2020 à 12:53, Vladimir Sitnikov <
> > sitnikov.vladimir@gmail.com>
> > a écrit :
> >
> > > Hi,
> > >
> > > >For 3 years I have been using the notion of Pacing an iteration to
> > > >facilitate the modeling of the load and also because it is very
> > practical
> > > >when we are doing loads with load steps
> > >
> > > Can you please clarify how pacing makes it practical?
> > >
> > > For instance, I have never faced a case when the non-functional
> > > requirements are expressed in terms of "pacing".
> > >
> > > I often see non-functional requirements like "100 requests per hour",
> > > "200 concurrent users, each making requests as fast as possible",
> > > "300 concurrent users producing 50 requests per hour", and so on.
> > > However, none of the above is like "5sec pacing".
> > >
> > > >The pacing could be declare in a new Thread Group field and/or in a
> new
> > > >component
> > >
> > > Have you checked "Precise Throughput Timer" and "Constant Throughput
> > Timer"
> > > ?
> > > A single timer like that at the beginning of the plan could be used to
> > > emulate "pacing".
> > >
> > > Vladimir
> > >
> >
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
Re: Add pacing feature
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
What about following use case:
- You have a number of virtual users running a scenario which is composed
of 30 steps related through correlation of ids
- You set thread group to Start next thread loop on error
- you don’t have a requirement of number of execution per minute
How do you avoid a burst in the first steps (the one before failure) of
your scenario when errors start to happen, ie abnormal increase of Home
Page calls or login process?
If we had notion of try/finally, it could be doable and solve also other
requirements like ensuring a session is disconnected even if error occurs
Regards
On Thursday, April 16, 2020, Antonio Gomes Rodrigues <ra...@gmail.com>
wrote:
> Hi,
>
> Pacing is used in Neoload, Loadruner...
>
> But I am agree with Vladimir, we can use "Precise Throughput Timer" and
> "Constant Throughput Timer"
>
>
> Le jeu. 16 avr. 2020 à 12:53, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com>
> a écrit :
>
> > Hi,
> >
> > >For 3 years I have been using the notion of Pacing an iteration to
> > >facilitate the modeling of the load and also because it is very
> practical
> > >when we are doing loads with load steps
> >
> > Can you please clarify how pacing makes it practical?
> >
> > For instance, I have never faced a case when the non-functional
> > requirements are expressed in terms of "pacing".
> >
> > I often see non-functional requirements like "100 requests per hour",
> > "200 concurrent users, each making requests as fast as possible",
> > "300 concurrent users producing 50 requests per hour", and so on.
> > However, none of the above is like "5sec pacing".
> >
> > >The pacing could be declare in a new Thread Group field and/or in a new
> > >component
> >
> > Have you checked "Precise Throughput Timer" and "Constant Throughput
> Timer"
> > ?
> > A single timer like that at the beginning of the plan could be used to
> > emulate "pacing".
> >
> > Vladimir
> >
>
--
Cordialement.
Philippe Mouawad.
Re: Add pacing feature
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Hi,
Pacing is used in Neoload, Loadruner...
But I am agree with Vladimir, we can use "Precise Throughput Timer" and
"Constant Throughput Timer"
Le jeu. 16 avr. 2020 à 12:53, Vladimir Sitnikov <si...@gmail.com>
a écrit :
> Hi,
>
> >For 3 years I have been using the notion of Pacing an iteration to
> >facilitate the modeling of the load and also because it is very practical
> >when we are doing loads with load steps
>
> Can you please clarify how pacing makes it practical?
>
> For instance, I have never faced a case when the non-functional
> requirements are expressed in terms of "pacing".
>
> I often see non-functional requirements like "100 requests per hour",
> "200 concurrent users, each making requests as fast as possible",
> "300 concurrent users producing 50 requests per hour", and so on.
> However, none of the above is like "5sec pacing".
>
> >The pacing could be declare in a new Thread Group field and/or in a new
> >component
>
> Have you checked "Precise Throughput Timer" and "Constant Throughput Timer"
> ?
> A single timer like that at the beginning of the plan could be used to
> emulate "pacing".
>
> Vladimir
>
Re: Add pacing feature
Posted by Vladimir Sitnikov <si...@gmail.com>.
Hi,
>For 3 years I have been using the notion of Pacing an iteration to
>facilitate the modeling of the load and also because it is very practical
>when we are doing loads with load steps
Can you please clarify how pacing makes it practical?
For instance, I have never faced a case when the non-functional
requirements are expressed in terms of "pacing".
I often see non-functional requirements like "100 requests per hour",
"200 concurrent users, each making requests as fast as possible",
"300 concurrent users producing 50 requests per hour", and so on.
However, none of the above is like "5sec pacing".
>The pacing could be declare in a new Thread Group field and/or in a new
>component
Have you checked "Precise Throughput Timer" and "Constant Throughput Timer"
?
A single timer like that at the beginning of the plan could be used to
emulate "pacing".
Vladimir