DEV Community: Shiyam

Beyond Brute Force: Adaptive Backpressure in API Traffic Simulation

Shiyam — Thu, 11 Jun 2026 15:03:35 +0000

If you've ever used a traditional load testing tool like k6, JMeter, or Locust, you've probably experienced the "Wall of Red."

You point your tool at a staging server, dial the concurrency up to simulate a major traffic spike, and suddenly your terminal is flooded with connection timed out and socket: too many open files errors. The load tester reports an 80% failure rate, and you conclude that your server can't handle the traffic.

But what if the server wasn't the only thing failing? What if your load testing tool was fundamentally misrepresenting reality by forcing the server into a catastrophic deadlock that wouldn't actually happen in production?

That is exactly why I built Gopher-Glide (gg). It is an open-source, pure-Go API traffic simulator (gopherglide.dev) designed to solve this exact problem.

In this post, I'll explain the architectural flaw shared by most modern load testers (The Closed Model), and show you how I used Mathematical Adaptive Backpressure to build an engine that extracts 3x more successful requests from a saturated server while using 40% less memory than k6.

The Problem: The "Closed Model" Brute Force

Most popular load testing tools operate on a Closed Model. To simulate 10,000 concurrent users, they spin up 10,000 independent "Virtual Users" (VUs) — usually backed by embedded JavaScript Virtual Machines or heavy OS threads.

When you ask a Closed Model tool to push 30,000 Requests Per Second (RPS), it blindly loops those VUs as fast as it can. But what happens when the target server (e.g., your NGINX proxy) hits its physical limit and begins to queue connections?

Latency spikes. The server takes 500ms to respond instead of 10ms.
The VUs get blocked. Because the VUs are stuck waiting for the slow server, the load tester isn't hitting its 30,000 RPS target.
The tool panics and spawns more. To try and hit the target RPS, the tool furiously spawns even more concurrent connections.
Catastrophic Deadlock. The server, already drowning in queued connections, is slammed with thousands of new ones. It completely locks up, dropping everything.

The load tester reports a 75% timeout rate. But in reality, an intelligent production edge-proxy (like Cloudflare or an API Gateway) would have gracefully shed the excess load, allowing the server to process at least some traffic successfully. The load tester didn't simulate reality; it simulated a DDoS attack.

The Solution: The Open Model & Adaptive Backpressure

I designed Gopher-Glide to act as a true Open Model load generator.

Instead of heavy Virtual Users, gg uses an asynchronous Actor Model built on Go's ultra-lightweight Goroutines. It completely decouples the generation of traffic from the waiting of responses.

But the real magic is how gg protects the target server using Adaptive Backpressure.

As gg pushes traffic, a lock-free metrics subsystem continuously calculates the P50 response latency. If the server begins to slow down, gg mathematically calculates exactly how many concurrent connections the server can physically handle. If the required concurrency crosses the physical threshold of the network, gg instantly engages a "Smooth Trim."

Instead of blindly opening thousands of dead-end sockets and forcing the target server into a total deadlock, gg gracefully throttles the excess traffic locally within the engine itself.

The "Mic Drop" Benchmark: gg vs. k6

To prove this architecture, I ran a saturation benchmark. I pointed both Gopher-Glide and Grafana k6 at a local NGINX server, and asked both tools to push an impossible 30,000 RPS for 30 seconds (attempting ~900,000 total requests).

Both engines correctly identified the physical limit of the target server: over 30 seconds, the NGINX server was physically only capable of accepting around 92,000 network connections.

But the outcomes of those 92,000 connections were vastly different.

🧠 Goodput Extraction

Metric	Gopher Glide (`gg`)	`k6`
Total Requests Sent	92,059	92,184
Successful Responses	76,140	25,753
Failure Rate	17.29%	72.06%

When k6 hit the server's limit, its Closed Model panicked and just kept violently spawning virtual users. It forced the NGINX server into a total deadlock where 72% of the connections timed out or were refused.

When gg detected the server slowing down, its Adaptive Backpressure instantly engaged. Because it stopped slamming the network with useless dead-end connections, the NGINX server was actually able to breathe. gg extracted 3x MORE successful responses from the exact same struggling server, out of the exact same 92k connection budget.

⚡ Memory Efficiency

Engine	Peak Memory (RAM)	Efficiency
Gopher Glide (`gg`)	1.42 GB	40% less RAM required.
`k6`	2.38 GB	Heavy JavaScript VM bloat.

Because k6 had to spin up thousands of heavy Goja JavaScript VMs to maintain its blocked Virtual Users, its memory ballooned to 2.38 GB.

Gopher-Glide simply parked its lightweight Goroutines and throttled the excess load locally, capping out at a completely stable 1.42 GB.

Stop testing load. Start simulating reality.

When building a high-traffic system, the goal isn't to see how quickly you can crash your server. The goal is to see how your architecture behaves under stress.

By natively mimicking the graceful load-shedding behavior of an intelligent edge proxy, Gopher-Glide ensures that your CI/CD runner is dedicated to maximizing successful Goodput, rather than fighting a JavaScript VM's garbage collector.

If you want to run high-fidelity API traffic simulations using nothing but the standard .http REST Client files already sitting in your IDE, check out the links below:

🌐 Website & Documentation: gopherglide.dev
💻 GitHub Repository: shyam-s00/gopher-glide

No JavaScript. No Python. No YAML configs. Just mathematically sound, pure-Go concurrency.

How I Built a Lock-Free Actor Model in Go to Hit 30k+ RPS (Zero Allocs)

Shiyam — Fri, 29 May 2026 14:32:42 +0000

How I Built a Lock-Free Actor Model in Go to Hit 30k+ RPS (Zero Allocs)

When it comes to building an API traffic simulator or a load-testing tool, the hardest problem isn’t sending the HTTP requests—it’s measuring them.

Most developers reach for traditional tools like JMeter (which uses heavy OS threads and consumes massive memory) or write scripts in interpreted languages like Python or JavaScript (Locust, k6) which introduce their own performance overheads.

My primary motivation for building an open-source tool like Gopher-Glide (gg) was simple: I wanted something incredibly lightweight, easy to use, and capable of running standard .http files straight from my IDE.

But simplicity shouldn't come at the cost of power. I wanted to see if I could build a tool this simple that could still match or exceed the raw performance of industry-standard tools like k6, hey, or Locust.

To achieve that kind of scale, I had to build a custom execution core in Go. I call it the Hive Engine. Here is how I used a pure-Go Actor Model and lock-free atomics to hit 0 allocs/op on the hot path.

The Problem: Mutex Contention and GC Pauses

In Go, it’s trivially easy to spin up 10,000 goroutines to fire off HTTP requests:

for i := 0; i < 10000; i++ {
    go sendRequest(client, req)
}

The problem arises when those 10,000 goroutines all need to report their metrics (latency, status codes, bytes transferred) back to a central state to display on a live terminal UI.

If you use a sync.Mutex to protect a shared metrics map, your 10,000 goroutines will spend 90% of their CPU time waiting in line to acquire the lock. This contention destroys throughput.

If you allocate new metric objects on the heap for every request and pass them through Go channels, the Garbage Collector (GC) will eventually panic, trigger a Stop-The-World pause, and completely ruin your latency percentiles (P99).

The Solution: The Actor Model

To solve this, I designed the Hive Engine using a lightweight implementation of the Actor Model.

In the Hive Engine, there is no shared memory. Instead, the architecture is split into three isolated tiers:

The Queen: The central director. It reads your traffic profile (e.g., ramping up to 5,000 RPS) and calculates exactly how many requests need to be dispatched every millisecond.
The Hatchery: The distributor. It receives micro-batches of work from the Queen and assigns them to available workers.
The Worker Bees (Actors): Isolated goroutines holding persistent, keep-alive HTTP connections.

By ensuring that each virtual client runs in its own isolated goroutine, we avoid all the traditional scheduling bottlenecks. The OS doesn't have to context-switch heavy threads, and the Go runtime handles the network I/O multiplexing natively.

The Secret Sauce: Lock-Free Atomics (`0 allocs/op`)

So how do the Worker Bees report their metrics without locking or triggering the GC?

Sharded, lock-free atomics.

Instead of creating a new metric struct on the heap for every request, the Hive Engine allocates a fixed-size, pre-warmed array of metric buckets when the simulation starts.

When an Actor finishes an HTTP request, it doesn't acquire a mutex. Instead, it uses sync/atomic to perform a lock-free hardware-level AddUint64 operation directly onto its assigned shard.

// Increment the request count without a lock, avoiding GC entirely
atomic.AddUint64(&metricsShard.TotalRequests, 1)
atomic.AddUint64(&metricsShard.TotalBytes, uint64(bytesRead))

Because these counters are pre-allocated and updated via hardware atomics, the hot path generates exactly 0 allocs/op. The Garbage Collector literally has nothing to clean up.

Every 100ms, the UI simply sweeps over these integer counters to calculate the live RPS and latency distributions.

The Result: Gopher-Glide

By combining the Actor Model with lock-free atomics, the Hive Engine comfortably pushes 30,000+ RPS per core, scaling linearly to ~89,000+ RPS on standard multi-core developer hardware.

If you want to see this engine in action - see https://gopherglide.dev

Instead of writing JS or Python scripts, gg lets you test your APIs using the exact same .http files you already use in your IDE.

# Run your existing API requests under heavy load, instantly
$ gg --hive-engine --profile flash-sale --http-file api.http

Try it out!

If you're interested in the code, or just need a wildly fast API simulator, check out the repository:
👉 Gopher-Glide on GitHub
👉 Full Documentation & Benchmarks

I’d love to hear how the engine handles your local workloads, and if you have any feedback on the Go actor implementation! Drop a star if you find it useful. ⭐

DEV Community: Shiyam

Beyond Brute Force: Adaptive Backpressure in API Traffic Simulation

The Problem: The "Closed Model" Brute Force

The Solution: The Open Model & Adaptive Backpressure

The "Mic Drop" Benchmark: gg vs. k6

🧠 Goodput Extraction

⚡ Memory Efficiency

Stop testing load. Start simulating reality.

How I Built a Lock-Free Actor Model in Go to Hit 30k+ RPS (Zero Allocs)

How I Built a Lock-Free Actor Model in Go to Hit 30k+ RPS (Zero Allocs)

The Problem: Mutex Contention and GC Pauses

The Solution: The Actor Model

The Secret Sauce: Lock-Free Atomics (0 allocs/op)

The Result: Gopher-Glide

Try it out!

The Secret Sauce: Lock-Free Atomics (`0 allocs/op`)