Dashboard toolsBuilt-in load test

Built-in load test

Mawjly ships with a one-click load test runner inside every app’s dashboard. Fire a controlled burst of trigger events at the cluster, see live progress, and get latency percentiles you can put in a capacity plan — no external tooling required.

Dashboard → your app → Load test

Why it’s useful

  • Pre-launch sanity check — confirm your plan tier handles the burst you expect.
  • Latency percentiles you can quote — p95 + max, not just averages.
  • Same path your code takes — uses the actual Pusher HTTP API, not a mock.

Run a test

FieldRangeMeaning
Channelany stringWhere the events publish to. Doesn’t need to exist.
Event[A-Za-z0-9_\-:.]+Event name.
Target RPS1 – 500Events per second. Free tier capped at 10 rps.
Duration1 – 120 secondsTotal run length.

Click Start. The active run polls every 1.5 s — you’ll see sent, failed, mean latency, and a sparkline of per-second throughput as it goes.

What gets measured

For each trigger call:

  • Wall-clock latency from request start to Sockudo’s response
  • Success/failure based on HTTP 2xx
  • Per-second sent/failed counts for the sparkline

When the run completes you also get mean / p95 / max latency across all sent events.

API

The dashboard is a thin wrapper over four endpoints:

POST   /api/apps/{app}/load-tests          # start a run (queued → running → completed)
GET    /api/apps/{app}/load-tests          # list past runs
GET    /api/apps/{app}/load-tests/{run}    # poll a single run

POST body:

{ "channel": "load-test", "event": "tick", "target_rps": 50, "duration_sec": 30 }

Limits

TierMax RPSMax duration
Free10120 s
Startup+500120 s

If you need a sustained 1k+ RPS soak test, contact us — we’ll spin up a one-off bench against a dedicated app.

Tips

  • Use a dedicated channel like load-test so you can filter it out of the debug console.
  • Run the test from the same region as production when comparing latency, otherwise you’re measuring the network path between your laptop and the dashboard server, not the cluster’s actual response time.
  • Watch the live debug console in another tab — every load-test event shows up there in real time.
WebhooksEvent schema validation