NetBench — HTTP load testing in your pocket
Hit an API with hundreds of concurrent users and watch throughput, latency percentiles and errors update live. Run a deep analysis on the desktop, or check prod from your phone while you're on call.
Running
Checkout API · 200 users
RPS
1 284
p95
123 ms
Errors
0.2%
Illustrative example of the live monitor.
What you test with NetBench
A k6, hey or wrk-style load generator with a real interface — for backend developers, SRE and QA engineers.
Capacity check before a release
Point a scenario at a new endpoint, raise concurrent users and watch where p95 and p99 start to bend. You get the throughput the service actually holds, not the one in the design doc.
On-call sanity check from your phone
Paste a URL into Quick test, run a short burst and see RPS, p95 and error rate on one screen. Enough to tell "prod is slow" from "my Wi-Fi is slow" without opening a laptop.
Before and after a deploy
Run the same scenario on the old and the new build and put the two reports side by side on the desktop. Regressions in latency or error rate show up as numbers, not impressions.
Finding the breaking point
Ramp-up adds workers gradually over a set time, so you can see the moment latency climbs or errors appear instead of hitting the service with everything at once.
Local and staging stands
Plain http:// targets work on Android and iOS too — local machines, VPN-only staging, containers on your LAN. Mobile platforms block cleartext by default; NetBench allows it on purpose.
Realistic traffic, not just GET /
Each virtual user walks through a list of steps — any HTTP method, path, custom headers such as Authorization, a JSON body — with optional think time between iterations.
Configure, run, read
Describe the load
- Target URL and a list of request steps
- Method, path, headers and JSON body per step
- Concurrent users and test duration
- Ramp-up and think time
Run and watch
- One async worker per virtual user
- Metrics refresh four times a second
- Stop at any moment — partial results are kept
- The UI stays smooth however hard the engine works
Read the report
- Summary of latency, throughput and errors
- Latency-over-time chart and status-code table
- Desktop: compare two runs side by side
- Export to JSON, CSV or HTML; copy a summary on mobile
What gets measured
Throughput
Requests per second, live
Latency p50 · p95 · p99
Percentiles from an HDR histogram
Min · mean · max
Full latency spread for the run
Error rate
Network failures and HTTP 4xx/5xx
Status codes
Breakdown of every response code
Active connections
Requests in flight right now
Bytes received
Total response traffic
Latency over time
Timeline chart in the report
Why a load tester is written in .NET
Load generation is the one kind of app where the runtime shows up directly in the results. That is exactly why NetBench is the Plumix showcase.
The tool must not be the bottleneck
A load generator that allocates per request ends up measuring its own garbage collector. In NetBench every result is a small readonly struct passed by reference, response bodies are drained into pooled buffers, and there is no LINQ on the hot path — so GC pressure stays flat and latency spikes belong to the server under test.
Concurrency is a language feature
Hundreds of virtual users are plain async Tasks throttled by a SemaphoreSlim. Results flow through a bounded Channel<T> with a single reader, counters use Interlocked, and CancellationToken stops a run cleanly mid-flight. No thread-per-user, no callback soup — on a phone as well as on a workstation.
One engine, every platform
The load engine, statistics and storage are one shared C# project. Desktop and browser get an Avalonia UI with MVVM; Android and iOS get a Plumix UI with Flutter-style widgets and Cubit state. The number you see on your phone comes from exactly the same code as the one on your desktop.
Native performance on mobile
NetBench runs on .NET 10 on the device itself, not in a web view and not through a remote agent. JSON is source-generated, so the app trims cleanly and starts fast, and the same profiling tools you use for backend .NET code work here too.
From a request to a pixel
Workers never touch the UI. Each result is recorded into lock-free counters and a histogram, and the screen receives one aggregated snapshot four times a second — whether the engine is doing ten requests per second or ten thousand.
- Virtual usersN async Tasks
- Channel<RequestResult>bounded, single reader
- AggregatorInterlocked + HDR histogram
- Snapshotevery 250 ms
- UIAvalonia or Plumix
public readonly struct RequestResult
{
public readonly long StartTimestampNs;
public readonly long EndTimestampNs;
public readonly int StatusCode;
public readonly int BytesReceived;
public readonly bool IsError;
public long LatencyNs => EndTimestampNs - StartTimestampNs;
}
// Hot path: no allocation per request
_aggregator.Record(in result);
await _channel.Writer.WriteAsync(result, token);One codebase, two UI stacks
The domain and data layers are shared. Each platform picks its UI half at compile time — no #if in the code.
Android & iOS
Plumix — Flutter-style widgets in C#
Coming to the stores
Windows, macOS, Linux
Avalonia — XAML + MVVM
Build from source
Browser
Avalonia on WebAssembly
Build from source
Your data stays on your device
No sign-up, no analytics, no ads, no NetBench servers. Scenarios, reports and settings are stored locally, and the app only sends requests to the targets you configure.
Privacy policyTest only what you're allowed to
NetBench generates real traffic. Point it at systems you own or have written permission to test — load against someone else's service without consent can be a denial-of-service attack.
Terms of useSupport
Found a bug or missing a feature? Open an issue on GitHub — that's where NetBench is developed in the open.