link1st/go-stress-testing: a Go load generator for HTTP, gRPC and 100w-connection runs

What go-stress-testing is for, and who actually needs it

The project is a load generator written in Go. The README describes the model plainly: each simulated user is a goroutine, and the tool is built to use CPU resources as fully as possible. That design decision sets the audience. If you are a backend engineer who wants to answer "how many requests per second does this endpoint sustain, and what do the latencies look like while it does", this tool is aimed at you. If you need a browser-driven journey through a checkout funnel, it is not.

The README frames the purpose in capacity terms: measure the QPS one machine can produce, then extrapolate how many machines a target user count requires. It also treats load testing as a rehearsal before launch, so that performance work or extra capacity happens before users arrive. That is a narrower and more honest pitch than most load testing tools make. The repository also carries a long explanatory article inside the README covering stress testing, concurrency testing and endurance testing, plus definitions of QPS, TPS, concurrency and parallelism. Useful for a team new to the discipline, unusual for a tool repository.

The goroutine-per-user model and the per-second report

The concurrency model is the whole architecture. The README states that each user is simulated with one goroutine, and the reported concurrency number is the number of goroutines started. The CLI exposes three parameters that define a run: -c for the concurrency, -n for the number of requests each concurrent worker performs, and -u for the target address. Total requests equal concurrency multiplied by per-worker count, so a run terminates on its own rather than needing a stop signal.

While the run is in progress the terminal prints one line per second. The columns are elapsed time, concurrency, success count, failure count, QPS, longest latency, shortest latency, average latency, and an error code tally. The README sample output shows the error code column formatted as code:count pairs, for example 200:100 for a hundred successful responses. At the end, a summary block reports the number of goroutines, total requests, total elapsed time, successNum and failureNum. The per-second cadence matters more than it looks: a single aggregate average hides the moment when a service starts queueing, and this output keeps that visible.

The repository layout backs up the protocol claim. There is a proto/ directory and a server/ directory alongside main.go, and go.mod requires google.golang.org/grpc and google.golang.org/protobuf, so gRPC support is compiled in rather than bolted on through a plugin. The README states HTTP 1.1 and 2.0 long connections are supported, and that private protocols need only a simple extension.

Installing go-stress-testing and running a first test

Two installation paths are documented. The first is a prebuilt binary from the releases page, which the README notes runs on macOS, Linux and Windows. The second is installation from source with a Go toolchain. The README gives this command, which installs the latest version into the directory reported by echo $GOBIN. If that directory is on your PATH through export PATH=$PATH:$GOROOT/bin:$GOBIN, the binary runs from any directory.

go install github.com/link1st/go-stress-testing@latest

After installing, ask the binary for its help text. The README shows the same pattern for the downloaded binary, where the filename carries the platform suffix.

go-stress-testing --help

The README's own first example runs against a public HTTPS endpoint with one concurrent worker and one hundred requests. The -u value is the address under test, so replace it with your own service before drawing any conclusion from the numbers.

go-stress-testing -c 1 -n 100 -u https://www.baidu.com/

Expect a table line every second, then a stat block. In the README sample the run finishes in about thirteen seconds with successNum 100, failureNum 0, and a QPS hovering around 7.6 to 8.1, with average latency near 128 milliseconds. Those figures describe the README author's machine and target, not yours. The shape of the output is the part worth learning: watch whether QPS flattens while average latency climbs, because that is the signature of a saturated target rather than a saturated client.

Where the tool stops being the right choice

The parameter set is the limitation. With only -c, -n and -u, a run is a fixed number of requests against one address. There is no documented facility in the README for chaining requests, extracting a value from one response and feeding it into the next, or varying the request body per user. A login-then-transact flow is therefore not expressible as a scenario; you would be measuring the login endpoint in isolation. Locust and JMeter both exist precisely because that gap is real, and the README itself covers them as alternatives.

The second limitation is the client machine. The README's headline achievement is one hundred million connections from a single machine, but the same document devotes a section to kernel tuning and client configuration before that run. That is an admission that the tool's ceiling is partly a kernel configuration problem, not purely a Go problem. If you cannot change sysctl settings on the load generator, or you are running it from a container with restricted limits, you will hit the wall before the tool does.

Third, the README does not document rollback or a stop-and-resume mechanism for a run, and it does not describe how to distribute load across multiple generators. Any large test is therefore a single-host test by default.

go-stress-testing against ab, Locust and JMeter

The README compares the common options directly, and the comparison is worth reading because it explains the design. ab is the simplest: a single binary, quick to point at a URL, but the README treats it as limited to straightforward HTTP benchmarking. Locust takes the opposite approach, describing load through Python code, which buys you realistic user journeys at the cost of running a Python process and writing that code. JMeter is the heavyweight, a GUI-driven platform with a large ecosystem, which is powerful for complex plans but awkward to put in a CI pipeline as a single artifact.

go-stress-testing sits between them. It is a compiled binary like ab, so there is nothing to install at run time beyond the binary itself, but it adds gRPC support and a per-second live report. The trade-off is that it gives up Locust's scripting model. If your test is "hammer this one endpoint and tell me the QPS and the latency distribution", the Go tool is the shortest path. If your test is "simulate a user who browses, adds to cart and pays", the scripting tools win, and no amount of Go performance changes that. The README also mentions cloud load testing services, which move the generator off your hardware entirely; that solves the kernel-tuning problem above, at the cost of running your test through someone else's infrastructure.

Releases, licence and the cost of upgrading

The release history is uneven. v1.0.16 added interface timeout configuration, v1.0.17 was an optimization pass, and v1.0.18, released on 2026-01-07, is described as enhancing the test report feature. The repository's last push was on 2026-09-21, so work is ongoing, but the gap between v1.0.17 in August 2024 and v1.0.18 in January 2026 shows that releases do not arrive on a schedule. Pin a version rather than tracking latest if you depend on report output, because the v1.0.18 change touched exactly that surface.

The build is straightforward. go.mod declares go 1.25.0 and a short dependency list: go-shellwords, golang.org/x/net, golang.org/x/text, gRPC, protobuf and layeh.com/radius. The Dockerfile is a two-stage build that compiles a static linux/amd64 binary with CGO_ENABLED=0 and ldflags "-s -w", then copies it into an ubuntu image whose entrypoint is sleep 36000. That entrypoint means the image is a container to exec into, not a service to run, so treat it as a build artifact rather than a deployable.

On licensing, the repository contains a LICENSE file at the top level, but GitHub reports the licence as NOASSERTION, meaning it could not match the file to a known licence. The README does not discuss licence terms. If you plan to redistribute the binary or embed it in a commercial product, read the LICENSE file yourself and get a lawyer's opinion; nothing in the repository substitutes for that.

Editorial conclusion

Adopt go-stress-testing if you want a single Go binary that drives HTTP 1.1 or 2.0 and gRPC targets, prints per-second QPS and latency, and can be installed with go install github.com/link1st/go-stress-testing@latest. Do not adopt it if you need scripted multi-step user journeys, distributed load generation, or a licence you can classify from the repository alone, since the licence file is present but GitHub reports NOASSERTION. Verify first that your target protocol is covered: the README states HTTP and gRPC are supported and that private protocols need a simple extension, so anything else is your code to write.

Frequently asked questions

Official sources

1. Issues
2. link1st/go-stress-testing on GitHub
3. README
4. Releases