Concurrency vs RPS: Which Load‑Testing Mode Boosts Service Performance?

This article explains how the two modes of the Forcebot load‑testing platform—Concurrency (virtual user) mode and RPS (Requests Per Second) mode—affect server performance indicators.

Background

Top internet companies require extremely low latency, with TP99 under 100 ms and even stricter TP999 requirements. To meet these goals, continuous optimization of interface logic and server performance is necessary. A new RPC interface for "product query tags" was developed, with external requirements of 200 QPS per machine and TP999 under 40 ms. Both Concurrency mode and RPS mode were used during testing, each showing different results. Concurrency mode helps determine the maximum number of simultaneous online users a system can support, while RPS mode measures overall throughput.

Concurrency Mode (Virtual User Mode)

Concurrency refers to the number of virtual users, i.e., the number of users online at the same time. It is suitable when you need to gauge how many simultaneous users each node of a business system can handle. The following diagram illustrates the request flow in Concurrency mode:

Key points:

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

The total duration of monitored performance metrics (TP99, TP999) consists of network transmission time, Jeff thread wait time, and method execution time.

The TPS metric represents the total number of requests sent per unit time.

Practical examples:

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

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

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 by setting a fixed request rate, eliminating the need to convert concurrency to RPS.

The following diagram shows the request flow in RPS mode:

Key points:

The load generator sends requests simultaneously according to the configured RPS, passing through network transmission and the Jeff thread pool before reaching the method logic.

The total duration of TP99/TP999 consists of network transmission time, Jeff thread wait time, and method execution time.

The TPS metric reflects the number of requests issued in a single burst.

Practical examples:

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

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

Conclusion

Comparing data from both modes yields the following insights:

Although Concurrency mode uses fewer virtual users than RPS mode, it generates higher TPS and higher observed QPS on the server side.

When the server receives a higher QPS under Concurrency mode, its TP99/TP999 metrics are better than those observed under RPS mode.

The reason is that Concurrency mode continuously sends requests, leading to a steady stream of tasks for the Jeff thread pool, which reduces waiting time and improves latency metrics.

Both modes show that internal UMP monitoring (availability, TP99, TP999) outperforms the metrics captured by Forcebot, because the latter also includes network transmission and thread‑pool delays, as well as potential GC pauses.