How to Design Effective Load Tests: Goals, Metrics, and QPS Estimation

Load Test Goals

Before creating a load‑test plan, clearly define the purpose. While the ultimate aim is to improve system performance, different goals require different approaches.

Identify system bottlenecks and optimize performance – especially for new systems lacking a performance baseline, iterative pressure reveals limits.

Establish performance baselines – collect maximum metrics (RT, error rate) and derive the highest sustainable QPS and concurrency.

Performance regression testing – verify that new changes do not degrade the established QPS/RT targets.

System stability – ensure the system can continuously meet SLA under sustained load, typically at 80% of peak traffic.

Network/line latency stability – assess latency across different network paths for latency‑sensitive services.

Load Test Objects

After setting goals, decide what to stress.

Backend

Single API

Specific business‑logic scenario

Frontend

Single request

Single operation

Single page

Overall page average

Load Test Data

Key metrics to monitor during testing:

QPS (queries per second)

RT (response time)

Success rate

Additional useful data:

Average page response time

Concurrency (less critical than QPS)

Maximum simultaneous online users

Network quality (latency, jitter)

Load Test Result Analysis

Analyze how QPS, RT, and success rate change as load increases to find the system’s balance point, ideally correlating with server‑side monitoring data.

Load Test Tools

Commonly used tool: JMeter with components such as:

Concurrent Thread Group

Java Sampler

Composite Chart (multiple charts combined with auto‑scaling axes)

Performance Metric Estimation Methods

Translate raw system metrics into user‑visible performance numbers.

Basic algorithm

1. Obtain daily PV/UV averages and peaks. 2. Choose the higher of (PV peak × 0.8) or daily average as target PV'. 3. Use PV' to estimate per‑minute API calls and derive required QPS. Assumptions: 80% of PV occurs in 20% of working hours (2/8 rule), front‑end request to back‑end API ratio = 1:10, each user performs ~10 page actions per minute during peak.

From the derived QPS, estimate concurrent users:

For 1‑minute window: N = QPS × 0.6

For 1‑hour window: N = QPS × 3.6

Forward and reverse calculations can validate whether the system can support observed user loads.

Other Considerations

Link tracing for bottleneck analysis

API logs and trace IDs

Cache impact on database

Whether to include the DB layer in the test

Generating realistic random data for cache‑related scenarios

Testing synchronous vs. asynchronous interfaces

Backend task processing capacity

Rate‑limiting at various layers (Sentinel, Nginx, LVS)

Message broadcasting performance

Database write consistency

Long‑chain call performance

Nginx/Tomcat configuration effects

Serialization/deserialization overhead

Hotspot data handling