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 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 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 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.vladi...@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
>>>
