Gatling constant concurrent users request per second

Question

I am running gatling script to measure my api performance. Below is the configuration which ramps up the user from 0 to 100 and eventually reaches 400 . Is is true to say in last step constantConcurrentUsers(400) 400 request called per second . Is below script calling 400 request/sec in last step ?

rampConcurrentUsers(0) to 100 during (1 minute),
constantConcurrentUsers(100) during (2 minute),
rampConcurrentUsers(100) to 200 during (1 minute),
constantConcurrentUsers(200) during (2 minute),
rampConcurrentUsers(200) to 300 during (1 minute),
constantConcurrentUsers(300) during (2 minute),
rampConcurrentUsers(300) to 400 during (1 minute),
constantConcurrentUsers(400) during (2 minute)

Answer 1

Absolutely not. Please read the documentation about injection models.

A closed workload model injection will guarantee the number of concurrent users, not the throughput.

For example, assuming scenario is 1 single request and response time is 250ms, 400 concurrent users would mean 400 * 4 = 1,600 requests per second (each virtual user perform 1 request in 250 ms, then is replaced with another one).

As explained in the documentation, closed workload models are definitely NOT the default to go.

You should design your injection profile and your scenario in order to match:

• your expected throughput
• AND your expected number of connections

Answer 2

Using the constantUsersPerSec instead of constantConcurrentUsers would be the better approach if you are trying to achieve a specific request/sec (RPS) value. It is worth noting that if you are running a script with a single API call, then the RPS will match the number of users being injected. However, if your script makes multiple API calls, then the response times of each API call will affect the RPS of subsequent API calls.