Mastering Stress Testing: From Basics to Go-Based Load Tools

What Is Stress Testing

Stress testing, also known as pressure testing, is a method to verify system stability by operating beyond normal limits to discover functional boundaries and hidden issues.

Why Perform Stress Testing

Simulate real‑user behavior to calculate machine performance (e.g., QPS per server) and estimate how many machines are needed to support a target user count such as 1 million concurrent users.

Pre‑emptively assess capacity before launch, allowing performance optimizations or provisioning of sufficient resources to ensure a good user experience.

Stress‑Testing Terminology

Test Types

Test Type                Description
Stress Testing          Also called "strength testing"; determines the maximum load a system can handle under high‑traffic conditions and identifies bottlenecks.
Concurrency Testing     Simulates many users accessing the system simultaneously to uncover issues such as concurrent reads/writes, thread contention, and resource contention.
Durability Testing      Runs the system under heavy load for an extended period to reveal problems like memory leaks, unreleased DB connections, or unreclaimed resources.

Key Terms

Term                     Explanation
Concurrency               The ability of a processor to handle multiple tasks logically at the same time.
Parallel                  Multiple processors or cores executing different tasks physically simultaneously.
QPS (Queries Per Second) Number of queries the server processes each second.
TPS (Transactions Per Second) Number of transactions (a group of requests) processed each second.
Request Success Number    Number of successful requests in a test run.
Request Failure Number    Number of failed requests in a test run.
Error Rate                Ratio of failed requests to total requests.
Max Response Time         Longest response time observed during the test.
Min Response Time         Shortest response time observed during the test.
Average Response Time     Average response time of all requests.

How to Calculate Stress‑Testing Metrics

Define a clear testing goal, such as achieving 100 QPS per server or supporting 1 million concurrent users.

Peak QPS Calculation

(Total PV * 80%) / (Seconds per day * 20%) = Peak QPS

Required Machine Count

Peak QPS / QPS per single machine = Number of machines needed

Example

Assume 30 million PV per day (100 W users) and a target of 1 million concurrent users.

(30,000,000 * 0.8) / (86,400 * 0.2) ≈ 1,389 QPS

If a single machine can handle 69 QPS, the required machine count is:

1,389 / 69 ≈ 20 machines

Traditional Stress‑Testing Tools

ab (Apache Bench) – Lightweight, built‑in Apache tool for basic HTTP performance testing.

wrk – High‑performance, event‑driven HTTP load generator supporting Lua scripts for complex scenarios.

siege – Feature‑rich HTTP tester supporting multiple methods, authentication, cookies, and detailed reports.

Locust – Python‑based distributed load testing framework with a web UI for real‑time monitoring.

JMeter – Apache’s full‑featured GUI/CLI tool supporting many protocols (HTTP, FTP, DB, etc.) and extensive result analysis.

Alibaba Cloud PTS – Cloud‑native performance testing service for large‑scale distributed tests with visual dashboards.

Go‑Based Stress‑Testing Tool (go‑stress‑testing)

Download the appropriate binary for your platform:

Linux (x64): gst-linux macOS (ARM): gst-mac macOS (Intel64): gst-mac-i386 Windows (x64): gst.exe Important Note : To avoid network and bandwidth interference, run tests in the same data center or on the same machine as the target service. When testing on the same machine, consider CPU contention; same‑rack testing is preferred for minimal impact.

Tool Usage

Give execution permission on Linux/macOS: sudo chmod +x gst-mac Run the tool and view output:

Quick Start (macOS / Windows)

macOS example: ./gst-mac -c 1 -n 100 -u https://www.baidu.com/ Windows example:

gst.exe -c 1 -n 100 -u https://www.baidu.com/

Parameters

-c

– Number of concurrent users (goroutines). -n – Number of requests per user (total requests = -c * -n). -u – Target URL. -p – Path to a curl‑style file for complex requests. -d true – Enable debug mode to show request/response details.

Result Display (example)

─────┬───────┬───────┬───────┬────────┬────────┬────────┬────────┬────────
 Time│ Concurrency│ Success│ Failure│ QPS │ Max Time│ Min Time│ Avg Time│ Error Code
─────┼───────┼───────┼───────┼────────┼────────┼────────┼────────┼────────
  1s │   1   │   8   │   0   │ 8.09 │ 133.16 │ 110.98 │ 123.56 │ 200:8
 ... (subsequent seconds) ...
*************************  Result Stat  ****************************
Goroutine count: 1
Total requests: 100, total time: 13.055 s, successNum: 100, failureNum: 0
*************************  Result End   ****************************

Parameter Explanation

Time : Duration of the test; the tool prints a line each second.

Concurrency : Number of active goroutines.

Success : Number of successful requests.

Failure : Number of failed requests.

QPS : Queries per second (requests processed each second).

Max/Min/Average Time : Response time statistics.

Error Code : HTTP status codes and their frequencies.

The most critical metric is QPS, which reflects the system’s capacity.

Testing a User API

When testing APIs that require custom headers, cookies, or POST bodies, you can either provide a curl‑style file or construct the request directly with parameters.

Method 1 – Use a curl file (no response output)

Save the generated curl command to baidu_api.curl.txt and run: ./gst-mac -c 100 -n 10 -p baidu_api.curl.txt or on Windows:

gst.exe -c 100 -n 10 -p baidu_api.curl.txt

Method 2 – Direct GET/POST parameters (response output)

macOS example with debug mode:

./gst-mac -c 2 -n 1 -d true -u "https://www.baidu.com/s?..." \
  -H "sec-ch-ua-platform: \"Windows\"" \
  -H "is_referer: https://www.baidu.com/" \
  -H "Ps-Dataurlconfigqid: 0xd5a20640000014a2" \
  -H "Referer: https://www.baidu.com/s?..." \
  -H "sec-ch-ua: \"Google Chrome\";v=\"137\", \"Chromium\";v=\"137\", \"Not/A)Brand\";v=\"24\"" \
  -H "sec-ch-ua-mobile: ?0" \
  -H "is_xhr: 1" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36" \
  -H "Accept: */*"

Windows multi‑line example (use caret ^ for line continuation) follows the same pattern. The output includes response bodies and detailed timing.

Conclusion

Stress testing is a crucial pre‑release step that uncovers system bottlenecks, guides capacity planning, and ensures stability under real‑world load. Choose tools based on scenario complexity: simple HTTP checks can use ab or wrk, while complex user‑behavior simulations benefit from Locust, JMeter, or cloud services like Alibaba Cloud PTS. Lightweight Go tools provide high performance with minimal overhead.

The real value lies in a well‑designed testing strategy, accurate baseline establishment, and thorough analysis of results. Test environments should mirror production as closely as possible to avoid network or bandwidth distortions. Integrating regular performance tests into CI/CD pipelines creates an automated guardrail for long‑term system health.

By applying scientific testing methods and the right tooling, teams can build more reliable, scalable systems and deliver superior user experiences.