Performance Testing Methodology and Case Study for a High‑Traffic Wallet System

1. Abstract

With the rapid growth of traffic for projects such as information pre‑placement and the Spring Festival red‑packet activity, the wallet system now faces performance requirements at the level of tens of thousands of requests per second, making systematic performance testing essential.

2. Performance‑Testing Requirement Analysis

The first step is to clarify what the test must achieve, typically a traffic forecast and a guarantee of system availability and stability. Requirements are gathered from three main sources:

Product requirements: PM‑provided traffic estimates for each interface, including peak QPS, derived from funnel models and user‑behavior analysis.

Product quality standards: Defined performance indicators that must be validated.

RD/OP requests: Specific tests for thread‑ratio configurations, database parameter impacts, and single‑module capacity to guide deployment and scaling decisions.

3. Overall and Detailed Test‑Plan Design

The design mirrors a product development process and considers four key factors:

Clear performance‑testing requirements.

System architecture analysis (e.g., nginx+lua front‑end, Redis clusters, BDRP database).

Understanding business flows to construct realistic test cases.

Available testing resources (machines, time, environment).

A complete test plan should include:

Performance environment deployment strategy.

Step‑by‑step testing procedures.

Interface and case design (e.g., request ratios a:b:c:d for the four red‑packet interfaces, dynamic user_id and phone generation).

Metrics to collect and expected thresholds (response times, request counts, resource usage).

System decomposition is crucial; the wallet system is split into five sub‑systems (red‑packet acquisition, reward data, async queue, coupon issuance, risk control) based on request coupling, with further hierarchical splitting when needed.

Various test environments are described:

New‑module machines before launch (ideal but rare).

Online testing on live services (high risk, requires careful ramp‑up and data cleanup).

Offline full‑system copy (accurate but resource‑intensive).

Offline sub‑system testing (common, less accurate).

Offline module‑level testing (easiest to obtain, useful for frequent regression).

4. Result Collection and Bottleneck Analysis

After execution, results are gathered and analyzed to locate bottlenecks, which fall into four categories:

Machine‑resource bottlenecks: CPU or network saturation; identified via monitoring, mitigated by optimization or scaling.

Thread‑rotation bottlenecks: Limits of synchronous processing per thread; addressed by adjusting thread counts or process architecture.

Single‑point lock bottlenecks: Contention on critical sections (often database rows); solved by reducing lock scope or sharding data.

Business‑logic bottlenecks: Complex flows that cause hidden delays (e.g., polling asynchronous results); require deep business understanding and possible redesign.

Examples from the red‑packet project illustrate each type and the corresponding mitigation strategies (e.g., expanding Redis shards, moving proxies, redesigning lock‑heavy operations).

5. Conclusion

The article summarizes the author’s understanding of performance testing, using the Spring Festival red‑packet project as a concrete example, and emphasizes that as traffic grows, systematic performance evaluation will become a routine part of development, providing valuable guidance for engineers entering the field.