Mark HollandSenior AI Solutions Engineer

Stress Tester

PrototypeBuilt at work for a national healthcare data company

Point it at a staging app, choose the load, and watch requests per second and latency move live. A demo mode produces synthetic results, so the dashboard can be shown without sending real load anywhere.

Stress Tester in demo mode: a completed test of 250 virtual users with a 10 second ramp-up over 60 seconds, a live chart of requests per second and average latency, and a run summary with p50, p95, and p99 latency.

What it does

  • One-session build with real and demo modes, pluggable auth, and full handoff docs.
  • VerifiedConfigurable runs from 1 to 10,000 virtual users, a live dashboard fed by Server-Sent Events, and a history of past runs to compare.

From my resume and the app's own materials. Facts marked Verified were checked against the code or a working copy of the app.

Who it is for

Developers who need to know how an internal app behaves under load before release.

How it works

Stress Tester, step by step

  1. Configure

    Target URL, virtual users from 1 to 10,000, ramp-up, and duration.

  2. Run

    An async runner drives the load against the target app.

  3. Watch

    Server-Sent Events feed a live chart of requests per second and latency.

  4. Compare

    Past runs stay sortable, with summary stats and request-level detail.

The real screens

Stress Tester in demo mode: a completed test of 250 virtual users with a 10 second ramp-up over 60 seconds, a live chart of requests per second and average latency, and a run summary with p50, p95, and p99 latency.
A completed run: 250 virtual users, live requests per second and latency, then the run summary. Shown with demo data.
Diagram: a browser dashboard, a FastAPI server with a live event stream, an async runner, and the target app in staging or QA, with SQLite locally or Postgres in production for run history.
Design diagramFour pieces and a database. In demo mode a synthetic generator replaces the live target.
Diagram: three design decisions, asyncio and httpx over Locust, real and demo run modes, and pluggable sign-in, each with why and what it gives.
Design diagramThree decisions, each with its reason and what it gave.

The decision that matters

asyncio and httpx over Locust

The popular load tool Locust clashes with the web framework this app runs on, so the runner uses Python's own async support with a small HTTP client library instead. The code is simpler, and it has room for 1,000 to 5,000 users.

Built with

  • FastAPI
  • asyncio and httpx
  • Server-Sent Events
  • Chart.js
  • SQLite locally, Postgres in production
  • Docker