Mastering QPS: From Basics to Real‑World Interview Wins

What Is QPS?

QPS stands for Queries Per Second, i.e., the number of requests a system handles each second. It can be thought of as the number of customers entering a busy restaurant per second, reflecting the system’s popularity and potential revenue.

QPS vs. TPS vs. Concurrency

QPS measures request frequency, TPS (Transactions Per Second) measures complete business transactions, and concurrency measures how many requests are being processed at the same moment. The three metrics focus on different aspects of system load.

QPS : request frequency (e.g., customers per minute in a restaurant).

TPS : business completeness (e.g., a whole table served from seating to checkout).

Concurrency : number of active requests (e.g., tables currently dining).

Typical QPS Ranges

Different system types have different reasonable QPS intervals:

Small internal systems : daily 10‑50, peak 100‑300.

E‑commerce detail page : daily 5 000‑20 000, peak 200 000‑500 000.

Payment core services : daily 1 000‑5 000, peak 10 000‑30 000.

Utility APIs : daily 100‑500, peak 1 000‑2 000.

How to Get Real QPS

1. Production‑Environment Monitoring

Collect real‑time QPS from the application layer (interface logs) and verify it with system‑level metrics.

Application‑Layer Methods

Log collection + visualization (ELK stack: Elasticsearch, Logstash, Kibana).

APM tools (SkyWalking, Pinpoint, Zipkin) for zero‑injection tracing.

Custom counters with time windows.

wrk -t10 -c1000 -d60s http://localhost:8080/api/goods

System‑Layer Validation

Correlate QPS with CPU, memory, network I/O (Prometheus + Grafana) and database metrics (Prometheus + mysqld_exporter / pg_exporter). If QPS spikes without corresponding resource usage, the data is likely inaccurate.

2. Load‑Testing Tools

Simulate extreme traffic to discover the system’s QPS ceiling.

JMeter : full‑stack performance testing, detailed reports.

wrk : lightweight, command‑line tool for quick QPS checks.

Locust : code‑driven, highly customizable load scenarios.

3. Manual Estimation

Use the simple formula QPS = total requests ÷ time window. Example: 360 000 requests in one hour → QPS ≈ 100.

Interpreting QPS

Turn raw numbers into business insight:

Understand the business meaning of the metric.

Detect abnormal signals (sudden drops, spikes, or large fluctuations).

Guide targeted optimizations (fix lock contention, adjust DB connection pools, mitigate cache avalanche, apply rate‑limiting).

Predict future risk and prepare capacity plans (peak‑QPS calculation, pre‑emptive scaling, degradation strategies).

Interview Guide

When asked about QPS in an interview, first explain the data source (e.g., Prometheus + Grafana for real‑time values, JMeter for peak testing). Then demonstrate the four‑step interpretation to show how you turn QPS into actionable decisions.

Conclusion

Understanding QPS, its relationship with TPS and concurrency, and how to measure and act on it turns a simple performance number into a powerful tool for system health, capacity planning, and interview success.