Article 04
Concurrent users, RPS, TPS and latency: reading system load correctly
Separate people, requests and transactions, then translate GA Realtime into an initial workload model without overclaiming.
RPS
250
p95
780ms
TPS
38
Example situation
Start with the people using the system
Ten thousand users do not mean ten thousand simultaneous requests
Some users read, some search and only a fraction save in the same second. Designing from total accounts can over- or underestimate demand. Behavior must be translated into concurrency, request rate and business transactions.
Summary for business and everyday users
Concurrent users, RPS, TPS and latency: reading system load correctly
Concurrent users are active in the same period, not total accounts.
RPS counts requests; TPS counts meaningful business transactions.
Read latency and error/resource metrics alongside throughput.
Interactive explanation
See how the stages connect before reading the detail
Select a stage to understand what happens, what evidence to inspect and how one decision affects the next stage.
Step 01 / 04
01 / Separate the units
Users, requests and transactions are different system views
One transaction may call several APIs and each API may query the database multiple times. These numbers form layers. Concurrency without behavior is insufficient for capacity planning.
Evidence to inspect
- Concurrent users: people active in the same window
- RPS: all requests per second
- TPS: business transactions per second
- Latency: response time, including p50, p95 and p99
In-depth explanation
Work through each issue in real operating context
Each section connects business impact with what a Tech Lead needs to inspect, including examples, evidence and constraints.
01 / Separate the units
01Users, requests and transactions are different system views
One transaction may call several APIs and each API may query the database multiple times. These numbers form layers. Concurrency without behavior is insufficient for capacity planning.
- Concurrent users: people active in the same window
- RPS: all requests per second
- TPS: business transactions per second
- Latency: response time, including p50, p95 and p99
- Error rate: failed-request share
02 / Workload model
02Start from behavior, then calculate RPS
Define actions per active user, requests per action and peak uplift. These multipliers should come from access logs, analytics or observation, not one default for every system.
Worked example
500 concurrent users
Each user creates 1.5 requests every 6 seconds with a 2x peak multiplier.
Base RPS = 500 × 1.5 ÷ 6 = 125; Peak RPS = 125 × 2 = 250250 RPS is an initial test target, not proof that production can support it.
03 / From GA to server
03GA Realtime is a starting point, not direct concurrency
GA shows users in a time window while servers receive requests each second. Translation needs active duration, page behavior, background calls and the share actively interacting. Compare estimates with access logs and server/database metrics.
SPAs may call several APIs per page view, while polling and retries raise RPS beyond visible interactions.
04 / Limits
04Equal RPS does not mean equal resource use
A cached read and a large report request have very different costs. Separate endpoints, payloads, query counts, external dependencies and cache hit rates before concluding capacity.
Checklist before action
Define active users
Identify key actions
Count requests per action
Separate business transactions
Derive peak multiplier from evidence
Compare with real logs
References
Figures and examples create a discussion framework. Validate them against the real system and its constraints before deciding.
- Reviewed by
- SIS Engineering
- Last reviewed
- 2026-07-17
Not sure where to start the review?
Use a preliminary tool or share the system context with SIS so the highest-priority work can be identified.