Comprehensive Full-Link Performance Testing Process and Practices for E-commerce Platforms

Background The original ZLJ marketplace relied on Alibaba Cloud PTS with limited testing capability, single‑interface scenarios, and no data‑driven capacity assessment, leading to ad‑hoc machine scaling.

What is Full‑Link Load Testing It simulates massive user traffic across the entire business chain in a production‑like environment, covering user scale, business scenarios, traffic sources, and aims to measure true service capacity.

When to Initiate Full‑Link Testing

Before expected traffic spikes (e.g., Double‑11/Double‑12 promotions) requiring large machine expansion.

When machine scaling does not proportionally increase service capacity due to downstream dependencies.

When service interactions become increasingly complex and single‑scenario testing is insufficient.

Performance Testing Approach

Design performance model based on product requirements and historical data.

Prepare test data and scripts, create whitelist users, and tag requests.

Define testing time windows and involve relevant technical owners.

Gradually increase load, capture performance breakpoints, and confirm target user count.

Use monitoring tools for real‑time metrics across servers, services, and call chains.

Compile test reports, note issues, and schedule follow‑up optimizations.

Clean up test data after completion.

Coordinate participants: Ops, R&D, DBA, QA, and Operations teams.

Full‑Link Testing Rollout

1. Environment Confirmation Testing is performed directly in the production environment to ensure realism and avoid configuration drift.

2. Data Preparation and Link Mapping

Identify core business links and clarify service boundaries.

Prepare realistic data from production, apply data masking, and isolate test data.

Exclude non‑critical flows (push, SMS, payment) from load testing.

3. Design Data Model Estimate traffic using the 80/20 rule (80% requests in 20% time) to calculate expected TPS.

4. Load Testing Platform Use JMeter for distributed load generation, integrate with performance monitoring, and implement automatic circuit‑break on error thresholds.

5. Capacity Planning

Estimate traffic from historical data.

Assess current machine count and required additions.

Refine capacity via full‑link testing to adjust resources.

Configure rate‑limiting to protect services.

6. Scenario Testing – Service Capacity Conduct single‑machine tests in production to capture true per‑machine capacity, using Nginx weight adjustments to direct traffic.

7. Process Notes Distinguish normal vs. test traffic, handle HTTP/gRPC, add random identifiers for downstream calls, and mock non‑essential services.

8. Monitoring and Issue Analysis

K8s and KVM resource monitoring (CPU, memory, network, disk I/O).

Application‑level metrics (TPS, latency, error rate).

Database and Redis monitoring.

Root‑cause analysis via traffic patterns, rate‑limit adjustments, and application degradation strategies.

9. Data Cleanup Remove whitelist users, expire coupon data, delete test products, and purge test orders after the test.

10. Test Results After Double‑11 and Double‑12 full‑link tests, ~50 performance optimizations were applied, including CPU scaling, code refactoring, caching, dependency tuning, and database fixes, ensuring stable core services for future promotions.

End Note The article concludes with a promotional section for ZuanZuan enterprise leasing services.