Orbitra Load Test: 480 req/s, Zero Errors, p99 182 ms

A tracker lives under load: every click is a write, a uniqueness check and a redirect. So before tagging v1.6.3 we rebuilt the uniqueness pipeline on a production-scale database and hammered it with stepped k6 load on our test bench. Here are the numbers.

Why we ran the test

v1.6.3 made the duplicate filter honest toward mobile NAT: the uniqueness key became IP + user agent instead of IP alone. Behind one carrier NAT IP, two different people used to collide — the second visitor got a subid with no click row in the database, and his conversion had nothing to attach to.

The change required a new ua_hash column and a composite index on a database already carrying real volume. That is the scariest kind of migration — so before tagging the release, we replayed the exact path a user install takes, on production-scale data.

The test bench

• Cloud container: 2 vCPU / 7 GB RAM, Ubuntu 24.04. nginx 1.24 + PHP-FPM 8.3 in the stock configuration exactly as install.sh leaves it — no manual tuning in the default runs.
• SQLite in WAL mode. k6 runs on the same box (~0.3 core of overhead), so the numbers are, if anything, understated.
• Stepped constant-arrival-rate load: 60 s per step, 5 s timeout, redirects not followed.
• Campaign: one regular stream → offer redirect, uniqueness window 24 h over IP + User-Agent. Unique requests use a random public IP and a unique UA; repeat visitors use 50 fixed IP/UA pairs.
• Three databases: ~50k clicks (sanity), 3.2M clicks (main), and a 3.9M-click pre-upgrade snapshot for the migration rehearsal (~1M of them in the last 24 hours, ~8,500 clicks per NAT IP).
• Paired runs: v1.6.2 served the same database next to the new build; after any collapsed run we waited out the FPM backlog before measuring again.

Results

And the migration rehearsal on the 3.9M-click snapshot: the first request after the “upgrade” ran migration 55 in 0.04 s, one cron pass built the index in 4.8 s and backfilled 1,008,085 UA hashes in 29.6 s — and NAT traffic at 480 req/s went through with zero errors and a 182 ms p99, every subid in the database. The previous version lost 27,775 subids in the same scenario; the new one lost zero.

Two details worth calling out. Even at 800 req/s — past the breaking point — every single served redirect was still written to the database: overload degrades latency, not durability. And hash correctness got its own check: a 2,000-row sample verified against PHP’s crc32 — zero mismatches.

The economics: one click costs about 2.5 ms of CPU, which puts the ceiling of a 2 vCPU box at ~550–600 req/s, CPU-bound. On 4 vCPU the same math extrapolates to ~1,000 req/s — measured on paper only, and labeled as such.

What the stress test caught before release

Half the value of the run is the bugs it flushed out — all fixed before the tag:

• Unclosed cursors on the click path caused instant SQLITE_BUSY_SNAPSHOT locks — returning visitors’ clicks went to the spool instead of the database.
• The debounce was keyed by IP alone, so NAT neighbours lost clicks and received a subid that did not exist.
• Report date filters used date(created_at, tz) and missed the index — reports crawled on big databases.
• A pixel INSERT had 23 columns and 22 values, so pixel clicks were silently dropped.
• Legacy rows with a NULL hash kept the NAT collapse alive for one uniqueness window after the upgrade.

Why it holds up

• SQLite in WAL mode, one file, zero extra services. No ClickHouse, Redis or MySQL eating RAM — the bottleneck is disk I/O, and it scales with your VPS.
• A write spool queue: if SQLite locks up for a moment, the click lands in a file queue that a per-minute cron flushes — the visitor’s redirect never waits, and the click is never lost.
• Uniqueness probes go by index: each click carries a compact crc32 UA hash, and the four uniqueness checks per click search the (ip, ua_hash, created_at) index instead of scanning all of an IP’s clicks.

Honest caveats

• Tested on the v1.6.3 release candidate. The storage architecture — SQLite, spool queue, indexes — is unchanged in current releases.
• Our bench is not your VPS: absolute numbers move with hardware. The ratios and the failure mode are what transfer.
• The 4 vCPU figure is an extrapolation, not a measurement — we say so rather than round it up.
• This was a synthetic stress run plus a production-scale migration rehearsal — not a real-traffic A/B against other trackers.

What this means for you

A modest VPS — the class most guides recommend for a start — already has headroom for serious daily volumes, and no per-event billing waits above it. If you are on Keitaro because “SQLite won’t survive”, this is the dataset to look at.

Orbitra installs on a clean Ubuntu server in about 15 minutes — one command, and the live demo is open if you want to poke around the panel first.

FAQ

Related reading