Hi, >
*Vincent mentions the pacing feature, however, I believe it is really reallyclose to my current proposal as well.For instance, "pacing of 1 min" means exactly the same as configuring "1request per minute".In other words, if you configure the new thread group to "1 request perminute", it would spawn exactly one request every minute (on average).If you configure "0.5 requests per minute" you get the same thing as"pacing 2 min".* When I model the load for the test, I reason in the theme of scenarios played per hour. Can the hardware architecture support for example : 200 new document creations per hour + 400 document searches per hour + 250 document modifications / hour. or for a merchant site : 1000 article consultations per hour + 1500 product searches per hour + 80 purchases per hour Usually I do not model the load in urls/sec but in full scenarios (from login to logout) per hour in high activity. Navigation scenarios can have alternative paths like searching which does not return any results. Modeling with a number of hits /sec or request/min is not easy. I prefer to use the concept of pacing which is simpler and which allows easily to make load with step (100% load 1h then 150% load 1h) Regards. Vincent DAB. Le mar. 9 nov. 2021 à 09:41, Vladimir Sitnikov <[email protected]> a écrit : > Mariusz>also discussion about JMeter threading model and constraints > > Frankly speaking, this time I just implemented the thread group the way I > wanted, and I did zero research on the past requests. > Thanks for the links above, and I think they discuss the very similar > problem and I think Kirk would appreciate the new thread group. > However, I'm not sure if Kirk uses JMeter often nowadays :-/ > > A "fun" discovery is my own mail on exactly the same issue from 2015: > https://lists.apache.org/thread/2mnjf3vv94ykc6zlk2qzmkt43z5rxbb0 > I've no idea why I dropped the idea then, however, the issue is exactly the > same as I resolve now. > > However, that idea was more involved and it included the proposal to > distinguish "start of test" from "preparation steps in each thread". > > --- > > There are lots of questions like "how many threads do I need", "why the > load does not match expectations". > For instance, > https://lists.apache.org/thread/syjbkcxk3cvp2c1g9hsxm8jcwc8776w1 > > There are lots of questions like "how do I configure X requests per > minute". > > Both topics are addressed by my current thread group. > > --- > > Vincent mentions the pacing feature, however, I believe it is really really > close to my current proposal as well. > For instance, "pacing of 1 min" means exactly the same as configuring "1 > request per minute". > In other words, if you configure the new thread group to "1 request per > minute", it would spawn exactly one request every minute (on average). > If you configure "0.5 requests per minute" you get the same thing as > "pacing 2 min". > > Currently "schedule string" contains "rate(X/min)", "radom_arrivals(X > min)", "even_arrivals(X min)", "pause(X min)" calls. > One can achieve "pacing" feature via "rate(${1/pacing}/min)". > Of course, I can add "pacing(X min)" macro that would be converted to > "rate(1/X)" in the internal representation, however, > I am not convinced it is worth adding taking into account it would make it > harder for the users to pick the right tool (they would have to choose > between rate and pacing). > > I think 99.42% of all SLAs were like "number of users", "max number of > concurrent requests", "number of requests per second". > I do not think I saw a non-functional requirement like "single thread must > not issue requests closer than X seconds". > > In other words, I think I understand what pacing means (thanks to Vincent's > explanation and pictures), however, I do not see which business > requirements > make "pacing" easier to configure and use in reporting to the management. > > The bad thing with pacing implementation, it would coordinate requests from > different thread groups magnifying coordinated omission issues. > > I would suggest configuring the request rate. > > Vladimir >
