How Full‑Link Load Testing Became the Secret Weapon for E‑Commerce Mega‑Sales

1. Background

Full‑link load testing is praised as the "nuclear weapon" for e‑commerce promotion preparation because it simulates massive user requests and data in a production‑like environment, revealing system bottlenecks and risks accurately.

Weimeng, a leading e‑commerce SaaS provider supporting hundreds of thousands of merchants, faced frequent incidents during major sales events (618, Double 11, Double 12). Before 2020, each promotion often resulted in online failures.

2. Challenges of Implementing Full‑Link Load Testing

Key problems identified from incident reviews:

Single‑interface load testing focus

Isolated testing per business line

Unrealistic test scenarios

Load‑testing tools unable to handle high QPS complex scenarios

In 2020, Weimeng committed to launching full‑link load testing for Double 11, requiring extensive preparation.

2.1 Solution Research

The goal was to make test results as realistic as possible by reproducing the production environment, using real transaction data, and modeling traffic that mirrors actual business patterns. Comprehensive monitoring and alerting were also required for rapid issue localization.

2.2 Current Situation

Prior attempts to adopt full‑link testing failed due to high refactoring costs, inconsistent component versions, and diverse technology stacks across business teams.

2.3 Design

The final implementation involved traffic identification refactoring, data isolation, and shadow storage configuration. An independent testing environment replicating core services was built, synchronizing configurations and anonymized data before the promotion.

2.4 Traffic Model

Weimeng's traffic model is complex, covering core transaction flows, various entry points (e.g., group buying, flash sales, mini‑programs, live streaming), and traffic proportion models derived from peak data of events like 618.

2.5 Testing Platform Challenges

Challenges included supporting over 100 core interfaces, targeting a QPS of 120 k+ (double the 618 peak), and enabling multi‑team collaboration for script creation, data construction, and real‑time result viewing.

3. Technical Highlights of the Load‑Testing Platform

3.1 Tool Selection

After evaluating Ngrinder and JMeter, JMeter was chosen as the engine due to its extensibility and superior support for complex scenarios.

3.2 Architecture

The platform consists of a Server side and Agent side. The Server manages data construction, scenario design, execution control, real‑time result display, historical result storage, and integration with monitoring, tracing, and alerting systems. Data storage uses MySQL for metadata and InfluxDB for real‑time metrics.

3.3 Platform Capabilities

Supports HTTP, HTTPS, Dubbo, and custom JAR testing

Traffic coloring for request identification

Three test modes (concurrency, RPS, fixed count) and five traffic models (fixed pressure, step increase, etc.)

Horizontal scaling of load generators, achieving >250 k QPS

Real‑time and historical result visualization

Performance defect management and knowledge base

Mock capabilities for third‑party services

Resource monitoring aggregation (pods, DB, Redis, ES, etc.)

Trace‑based top‑latency node analysis with trend comparison

3.4 Product Demonstrations

Various scenarios were tested, including core retail and live‑streaming flows, each with dozens of interfaces. The platform executed over 5 000 tests during Double 11, raising QPS from under 10 k to over 100 k for retail and achieving a 1.8× increase for live streaming.

4. Link‑Monitoring Practices

Each interface generates a trace. By analyzing traces, Weimeng builds an application list (derived from APPID and CMDB) and an interface list, enabling monitoring of dependent resources such as MySQL, Redis, ES, and Kafka.

Trace analysis identifies top‑latency APIs and provides version‑based baseline comparisons for anomaly detection. Both manual and automatic trace management are supported.

5. Future Plans

The platform aims to evolve into a comprehensive stability assurance system, integrating SLA management for both load testing and fault‑injection drills. Ongoing work includes expanding fault‑exercise scenarios, standardizing templates, and tighter integration between testing and incident‑response workflows.