I. Preparatory Phase

Performance testing (actual execution) begins after core features stabilize, but early involvement in the requirements phase is critical. This allows understanding business logic and key workflows to inform later testing.

II. Performance Requirement Analysis (Review)

During the review, define the testing scope and objectives. Stakeholders without performance expertise may propose unrealistic targets (e.g., 100k TPS on a single server). To avoid this, guide teams (product, dev, etc.) to set feasible goals for single-scenario, mixed-scenario, and stability tests. Document agreed targets via email (shared accountability if issues arise post-launch).

• Iterative projects: Derive metrics from production monitoring/logs (e.g., TPS, resource usage).
• New projects: Conduct independent capacity planning.

Key metrics: TPS (transactions per second), average response time (ART), concurrency, and resource utilization (CPU, memory, IO, network) across services.

III. System Architecture & Environment Setup

Understand the system’s infrastructure (web/app/cache/database/file servers) to identify monitoring targets. Common tech stacks: Nginx, Dubbo, MySQL, Redis, JVM. Coordinate with teams to secure a dedicated test anvironment.

IV. Test Plan Development

Create a plan covering:

• Project background and architecture analysis.
• Resource requirements (hardware, tools like JMeter, monitoring scripts).
• Technical strategies (tool selection, scenario design for peak/stability tests).
• Timelines (e.g., script development, test execution, reporting).

V. Test Environment & Data Preparation

Set up the test environment (collaborate with ops/dev if needed). Prepare two types of test data:

• Baseline data: Reuse/modify data from functional testing (e.g., user accounts, configurations).
• Business data: Include existing (stored) and planned (capacity) datasets. For example, a query API’s performance differs with 10k vs. 100k records. Align data volume with production; test both empty and pre-loaded states for new systems.

VI. Test Script Development

After core workflows stabilize, debug APIs and develop load scripts (e.g., using JMeter—open-source, lightweight, and feature-rich). Adjust scripts with:

• Parameterization (dynamic data injection).
• Correlation (handling session/cookie dependencies).
• Transactions (marking business-critical steps).
• Checkpoints (verify response validity).
• Think time (simulate user delays).
• Header management (e.g., authentication, content-type).

Note: JMeter is a client-side tool—JMeter ≠ performance testing (it only generates load).

VII. Baseline Testing (Pre-test)

Run a baseline test with low concurrency (e.g., 1 user) for 10 minutes:

1. Verify end-to-end functionality in the test environment.
2. Estimate the volume of parameterized data needed for full-scale testing.

VIII. Execute Testing & Monitor Metrics

Run designed scenarios and monitor metrics (TPS, ART, resource usage). If targets aren’t met, analyze bottlenecks:

• Direct analysis: Check pre-identified bottlenecks (e.g., high CPU usage, slow queries).
• Step-by-step diagnosis: Trace requests through servers (check resource limits, queues, thread pools, deadlocks, slow SQL, long transactions).

Monitoring Tools/Commands

• Linux servers: top, vmstat, free, df, sar, iostat, netstat (combined for holistic insights).
• Java apps: jvisualvm, jconsole, jmap, jstat, jstack (or custom shell scripts).
• Databases (Redis, MySQL) and JVM: Specialized tools (covered in future articles).

IX. Bottleneck Analysis & Root-Cause Identification

Use monitoring data to isolate issues (module-level analysis, logs, memory/thread dumps, code tracing). This requires practical experience—training alone may not suffice (e.g., trained testers often struggle with real-world debugging).

X. Performance Optimization

After identifying bottlenecks, propose optimizations (or share findings with devs). Dev teams will evaluate and implement fixes. Even without solutions, learning from devs’ optimization logic accelerates growth.

XI. Performance Regression Testing

Retest after optimizations to validate improvements (e.g., TPS increase, response time reduction).

XII. Performance Report

Document:

• Test results (e.g., TPS = 500, ART = 200ms, resource usage).
• Pass/fail status (against defined targets).
• Idantified issues, root causes, and solutions.
• Performance improvements (e.g., 3x TPS after optimization).
• Detailed optimization steps (for cross-environment consistency).