This folder contains practical scripts for load testing the ingestion and processing flow, plus comparing gzip vs plain request performance.
Sends gzip-compressed event batches to POST /api/v1/events.
- Sends bursts of
REQUESTS_PER_BURSTrequests in parallel. - Each request contains
EVENTS_PER_REQUESTevents. - Starts a new burst every
INTERVAL_SECONDSseconds. - Runs continuously until you press
Ctrl+C(firstCtrl+Cstops gracefully after the current burst, secondCtrl+Cexits immediately). - Payloads are generated to satisfy the ingestion validator constraints.
Run:
bun scripts/send-gzip-events.tsBenchmarks plain JSON requests against gzip-compressed JSON requests for the same event workload.
- Runs
REQUESTS_PER_MODErounds. - Sends one plain and one gzip request per round.
- Alternates order to reduce measurement bias.
- Reports reliability, bandwidth, and latency (
avgandp95).
Run:
bun scripts/benchmark-gzip-vs-plain.ts--- Benchmark Summary ---
Endpoint: http://localhost:3000/api/v1/events
Requests per mode: 1000
Events per request: 100
Reliability:
plain: success=1000 failed=0
gzip: success=1000 failed=0
Bandwidth:
plain sent bytes: 29.51 MB (30940393 B)
gzip sent bytes: 1.76 MB (1841165 B)
bandwidth saved with gzip: 94.05%
Latency (202 responses only):
plain avg=21.05ms p95=24.60ms
gzip avg=21.06ms p95=24.52ms
avg latency gain with gzip: -0.02% (-0.00ms)
p95 latency gain with gzip: 0.35% (0.09ms)
Given the nature of our request body and the repetitive JSON structure/keys, we managed to reach an astonishing ~94% bandwidth reduction with gzip (this benchmark used a fixed payload size of 100 events per request; in a real setup where events are flushed in time windows, for example every 10 seconds, batch sizes will vary, so the 94% figure will likely decrease somewhat, but the improvement should still remain substantial).