Hi,
If you want to fire 100 GET requests per second (10 in parallel) for a period of 1 minute
then one candidate way of implementing this is to have 10 users injected executing a scenario that loops forever (with a maxDuration on the simulation).
If there was no pause in the scenario and only 1 request then the response time of the GET request needs to be exactly(or slightly less than) 0.1 seconds to achieve the total of 100rps(requests per second).
The problem is we don't know in advance what the response time might be, and it will vary. This will affect your throughput. So the requirement will be hard to meet.
1) You could use pacing( http://gatling.io/docs/2.0.0-RC2/general/scenario.html?highlight=pacing#pace ) to achieve a constant throughput with a fixed number of looping users. But then your users will some of the time be inactive not sending a request. The pacing also has some risks where it can cause coordination with the test environment that can invalidate percentiles results etc.
Pacing is the workaround for thread-per-user tools like JMeter to approximate an open workload with an arrival rate. There may be a use case for it in Gatling but for the most part cUps() will provide a cleaner workload.
2) If the response time was way less than 0.1s you could use throttling. However, if the response time degrades enough >0.1s then the throughput will drop accordingly with 10 looping users, missing the 100rps target.
Having said that, where does the requirement for 10 in parallel come from?
Typically either the workload of the system is applying a request rate(open), or it is applying some parallel load/concurrency(closed), not both at the same time (although it is possible). The check is whether the requirement is valid or not.
thanks
Alex