jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Daburon <vdabu...@gmail.com>
Subject Re: Add pacing feature
Date Fri, 17 Apr 2020 08:06:56 GMT
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 <vdaburon@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 <vdaburon@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 <vdaburon@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
>>>>
>>>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message