Real-time test result aggregator for distributed load tests

When an engineer runs a distributed load test across multiple servers and tries to watch results come in live, the complaint is consistent and specific: 'quite slow if you will try to transfer test results from multiple servers in real time.' The problem isn't that they can't eventually see the results — it's that the live view lags, which means they can't make real-time decisions about whether to abort a test run, adjust load parameters, or flag a degradation event while it's happening.

This gap exists because the open-source testing tools that dominate distributed load testing were designed around batch result collection — results get written to files or a backend, and you analyze them afterward. The real-time streaming layer was bolted on later, or delegated to third-party dashboards that require significant setup and don't speak the native result format fluently. The people who need live visibility are performance engineers running high-stakes load tests before releases, but the vendors' incentive is to improve test authoring and scenario definition, not result streaming.

The structural awkwardness is that aggregating results in real time across 10 or 20 load generators requires a purpose-built ingestion and fan-in layer — it's not something you add to a test runner without fundamentally changing the architecture. So incumbents don't do it, and users end up watching a frozen dashboard or refreshing a CSV export every few minutes during a test that matters.

A business exists here because distributed load testing happens repeatedly — before every major release, during capacity planning, after infrastructure changes. Each test run where the live view lags is a run where the engineer can't intervene intelligently. If a test is degrading production unexpectedly, the 3-minute lag in the dashboard is the difference between catching it and rolling back versus causing an incident.

What to build

Build a result streaming server that accepts metrics pushed from distributed JMeter or Gatling agents via a lightweight agent process, aggregates them at sub-second intervals, and renders a live dashboard showing p50/p95/p99 latency, error rate, and throughput per agent and in aggregate — no manual dashboard configuration required.

Where to start

Start exclusively with JMeter users running tests on AWS, where the network topology is predictable and the agent can be distributed as a pre-built AMI that installs in one command — removing the setup friction that currently makes real-time aggregation feel not worth the effort.

The hard part

The hardest early problem is that performance engineers are deeply skeptical of adding another agent process to their load generators — any overhead from the streaming agent will corrupt their test results, so the agent has to be provably near-zero CPU and memory impact before anyone serious will trust it.

How it makes money

Usage-based pricing per test run or per concurrent virtual user, with a free tier up to 100 VUs so teams can validate the accuracy before committing — upsells to higher VU limits and result retention for trend analysis.