Comprehensive Load‑Testing Plan and Implementation Using JMeter, Docker, and a Monitoring Stack

Project Background – The existing long‑connection server suffers from low reachability, no point‑to‑point push, difficult troubleshooting, and limited protocol support, prompting the development of a self‑built long‑connection system.

Testing Objectives – Determine performance indicators, locate bottlenecks, assess service availability and stability after the new system goes live.

Testing Scenarios – (1) New system launch to verify capacity, (2) Performance probing to identify bottlenecks, (3) Capacity planning for precise resource allocation.

Testing Strategies – Baseline testing, load testing, stress testing, and stability testing (5‑7 days at slightly below peak load).

Pressure Generation Strategy – Use a single pressure machine for TPS ≤ 1000 , switch to distributed pressure for higher loads; multiple machines for cluster tests.

TPS Estimation – Example calculations: 10 billion users → ~46 300 TPS (2500 TPS per machine with 20 machines); 1 million users → average 10 TPS, peak 50 TPS per machine.

Metric Definitions – Business metrics (RT TP95), resource metrics (CPU ≤ 85 %, RAM ≤ 80 %, Disk I/O ≤ 90 %, Network I/O ≤ 80 %), middleware metrics (firewall, Nginx, Redis, MySQL slow queries, thread blocking, deadlocks, missing indexes).

Testing Process

1. Requirement analysis – clarify system under test, scenarios, content, strategy, and indicators.

2. Test plan creation & review – combine previous sections, include machine info, and draft an outline.

3. Test case design & script writing – select JMeter components (Thread Group, HTTP Sampler, WebSocket Sampler, Pre‑Processors, Post‑Processors, Assertions, Listeners). Example variable generation:

m2   ${__RandomString(44,0123456789qwertyuiopasdfghjklzxcvbnm,)}
mid  ${__RandomString(32,0123456789qwertyuiopasdfghjklzxcvbnm,)}

4. Execution – build environment (Windows GUI/CLI, Linux CLI, Docker‑based distributed), run scripts with appropriate JMeter CLI flags (e.g., -n -t test.jmx -l result.jtl -e -o report -JthreadNum=10 -JrampTime=20 ), and schedule slaves via -r or -R options.

5. Result recording – generate HTML reports, aggregate data, and store for baseline comparison.

6. Issue analysis & optimization – identify non‑performance‑related problems and perform tuning.

7. Report output – include background, participants, timeline, environment, data construction, strategy, execution log, bottleneck identification, and optimization steps.

Execution Modes – GUI (for debugging only), distributed GUI, CLI on Windows, CLI on Linux, Docker‑based distributed execution. Docker images are built from a CentOS‑7 Java‑8 base, with separate master and slave images (e.g., FROM handan0723/jmeter-base:v2 and exposing ports 1099, 50000).

Monitoring System – Real‑time data collection via JMeter Backend Listener, storage in InfluxDB (or Prometheus), visualization in Grafana. Services are orchestrated with Docker‑Compose, including Redis, cAdvisor, Prometheus, InfluxDB, and Grafana.

Conclusion – The document provides a high‑level overview of the load‑testing workflow, tools, scripts, execution methods, and monitoring setup, laying the groundwork for detailed implementation in subsequent chapters.