Calculate System Throughput: QPS, TPS, Concurrency & Response Time
This article explains key performance testing concepts such as system throughput, QPS/TPS, concurrency, response time, and their interrelationships, provides practical calculation examples, shows how daily PV relates to TPS for different platforms, and outlines essential metrics and formulas for evaluating software performance.
A system's throughput (capacity) is closely linked to the CPU consumption per request, external interfaces, and I/O; higher CPU usage per request reduces overall throughput.
Key throughput parameters are QPS (TPS), concurrency, and average response time.
These relate as QPS = concurrency / average_response_time or concurrency = QPS * average_response_time.
Example: In a sign‑in system with 1,000 employees logging in during a 30‑minute window, each login lasts 5 minutes. QPS = 1000 / (30*60) ≈ 0.56 req/s, average response time = 5*60 = 300 s, so concurrency = 0.56 * 300 ≈ 166.7 users.
Throughput is limited by the lower of QPS and concurrency; when either reaches its maximum, additional load reduces performance due to overload, context switching, and memory pressure.
Response time is determined by a critical path consisting of CPU processing, I/O, and external system latency, similar to a project's critical path.
When evaluating system throughput, consider CPU, I/O, and external response factors, as well as daily page views (PV). Observing logs often shows consistent traffic patterns, allowing PV to be inferred from peak QPS.
Typical relationships:
Taobao: max_TPS : PV ≈ 1 : 11*3600 B2B Chinese sites: max_TPS : PV ≈ 1 : 8 hours Thus, if a test yields TPS = 100, daily throughput ≈ 100 * 11 * 3600 = 3.96 million requests.
The general formula linking TPS, concurrent users, response time, and think time is TPS = concurrent_users / (response_time + think_time).
Software Performance Testing Basic Concepts and Formulas
Performance concerns differ by role:
User : perceived response time from action to result.
Administrator : response time, resource utilization, scalability, maximum concurrent users, bottlenecks, 24/7 availability.
Developer : architecture, database design, code efficiency, memory usage, thread synchronization, resource contention.
Performance Test Engineer : all of the above.
Key terminology:
Response time = network transmission (N1+N2+N3+N4) + application server processing (A1+A3) + database processing (A2).
Concurrent users = RPS + concurrent connections + think time.
Average concurrency C = nL / T where n = daily active users, L = average session length, T = observation period.
Peak concurrency ≈ C + 3·√C (Poisson approximation).
Throughput F = VU * R / T where VU = virtual users, R = requests per user, T = test duration.
Performance counters (CPU, memory, process time) are essential for monitoring and bottleneck analysis.
Think time (TS) models user pause between requests: TS = T / R. It can be derived through steps: compute concurrent users, measure average throughput, calculate requests per user, then obtain think time.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITFLY8 Architecture Home
ITFLY8 Architecture Home - focused on architecture knowledge sharing and exchange, covering project management and product design. Includes large-scale distributed website architecture (high performance, high availability, caching, message queues...), design patterns, architecture patterns, big data, project management (SCRUM, PMP, Prince2), product design, and more.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
