Fixed Rate Generator Varying Requests
Hello all, I have the fixed rate generator component connected to to the SOAPUI Runner.. I set the Fixed Rate Generator to 4 requests per second and when looking at the statistics tab I will see a...
Forum Discussion
OstbergM
Staff
StaffYou are wrong in the fact that LoadUI does not wait for a request to return before sending a new one, at least not when you are using the Fixed Rate component (Fixed Load is another story).
The fixed rate sends out X number of requests each second, no matter if the server can handle it or not.
This makes it real obvious to see what happens when the server can't handle more requests.
The statistics count responses that arrived during the latest second and the latest second only.
This means that some requests leak into the next second because they may take an arbitrary amount of time to return.
Internally this is because the timer that sends requests from a generator (G-timer) and the timer that displays data (D-timer) are not the same, but are started at roughly the same time. This means that if G-timer triggers requests just before D-timer starts collecting data then some requests may return before the D-timer collects them, thereby ending up in the previous data-point.
These variances in the number of requests sent/received should be taken with a grain of salt and are mostly only visible on very tiny loads.
I hope that explains your pondering somewhat.
Best,
Osten
The fixed rate sends out X number of requests each second, no matter if the server can handle it or not.
This makes it real obvious to see what happens when the server can't handle more requests.
The statistics count responses that arrived during the latest second and the latest second only.
This means that some requests leak into the next second because they may take an arbitrary amount of time to return.
Internally this is because the timer that sends requests from a generator (G-timer) and the timer that displays data (D-timer) are not the same, but are started at roughly the same time. This means that if G-timer triggers requests just before D-timer starts collecting data then some requests may return before the D-timer collects them, thereby ending up in the previous data-point.
These variances in the number of requests sent/received should be taken with a grain of salt and are mostly only visible on very tiny loads.
I hope that explains your pondering somewhat.
Best,
Osten