Impact of Concurrency Mode vs RPS Mode on Service Performance Metrics in Forcebot Load Testing

Guide This article explains how the two modes—Concurrency Mode and RPS Mode—of the Forcebot load‑testing platform affect server‑side performance indicators, using a “product query tag” test case to compare TPS, TP99 and TP999.

1. Background Leading internet companies require interface response times below 100 ms for TP99 and often stricter for TP999. A “product query tag” RPC interface was developed with a target of 200 QPS and TP999 under 40 ms. Both Concurrency Mode and RPS Mode were used during testing; Concurrency Mode estimates the maximum simultaneous online users, while RPS Mode measures overall throughput.

2. Concurrency Mode (Virtual User Mode) Concurrency refers to the number of virtual users, i.e., simultaneous online users. It is suitable when the goal is to determine how many users each node can handle. The following flow diagram illustrates the request process in Concurrency Mode:

Summary of Concurrency Mode:

The load generator sends requests continuously according to the configured concurrency, passing through network transmission and the Jeff thread pool before reaching the target method.

The total latency measured for TP99/TP999 consists of network transmission time, Jeff thread‑pool waiting time, and method execution time.

TPS is the total number of requests issued per unit time.

Practical Example:

Forcebot monitor – Concurrent users: 1; Average TPS: 330; TP99: 4 ms; TP999: 5 ms

Umpkey monitor – QPS: 300; TP99: 1 ms; TP999: 1 ms

3. RPS Mode RPS (Requests Per Second) measures the number of requests issued each second. It is a throughput‑oriented mode that directly evaluates system capacity from the server side, bypassing the conversion from concurrency to RPS.

Summary of RPS Mode:

The load generator issues the configured number of requests simultaneously in a single burst.

The measured TP99/TP999 latency again comprises network transmission, Jeff thread‑pool waiting, and method execution times.

TPS reflects the total number of requests sent in that burst.

Practical Example:

Forcebot monitor – Concurrent users: 50; Average TPS: 47; TP99: 6 ms; TP999: 60 ms

Umpkey monitor – QPS: 50; TP99: 1 ms; TP999: 1 ms

4. Conclusion Comparing the two modes reveals that, despite lower concurrent user counts, Concurrency Mode often yields higher TPS and lower TP99/TP999 values than RPS Mode because it continuously generates requests, whereas RPS Mode emits a single burst. Additionally, lower concurrency reduces pressure on the Jeff thread pool, shortening wait times and improving latency metrics. These observations can guide developers in selecting the appropriate load‑testing mode for their services.