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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >>> [email protected]> 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 >>>> >>>
