Rate and simultaneous work
Requests per second describes a rate over a time interval. Concurrency describes how much work is in progress at the same time. The two are related, but they are not interchangeable.
A system can keep many slow requests open while completing relatively few each second. Another workload may complete many short requests with much less simultaneous work.
Know which concurrency is being counted
A product can use the word concurrency for active connections, virtual users or simultaneous test jobs. Those are different controls. On the pricing cards, concurrent tests refer to how many test runs your account can run at once, not a guaranteed request rate.
Keep this distinction with your configuration when comparing plans or results. A count of simultaneous test jobs does not by itself specify the traffic profile inside each job.
Measure the outcome
Read achieved throughput and response times from the actual run. They depend on the scenario, the target and the test infrastructure. Do not infer production capacity from a single configuration number.
- Write down what the concurrency setting counts.
- Record the observed request rate.
- Compare latency and failures at that rate.
- Keep the same scenario when comparing runs.
Use a baseline
Start with a workload you understand and increase one variable at a time. When response time or error rate changes, connect it to the configuration and the application metrics before drawing a conclusion.