Performance, measured · OpsChisel DLQ Manager for Azure Service Bus

230,000+

dead-letters captured in a single session - zero lost, every count reconciled against Service Bus down to the last message.

590 / second

sustained peak - 105,000 banked dead-letters drained in 4 minutes 8 seconds (425 per second on average over the burst, run 14, October 2026) the moment capture was switched on.

25 ms

median namespace-stat response on the server during that drain; operator clicks 0.2-0.3 s end to end. People browsing, searching and resending never felt the storm underneath.

0

failed writes and zero red errors in the operator console - even with the write side throttled at the per-tenant storage ceiling for four minutes.

Batch storms are invisible to the people using it

The architecture separates the write path from the read path at the database level: capture writes run at low priority, operator reads at high, each with its own dedicated throughput budget. When 100,000 dead-letters arrive at once, the pump takes the pressure - the console doesn't.

Namespace dashboards answered at p50 25 ms on the server (p50 19 ms / p95 124 ms in the earlier 230,000-message session) while capture ran at full speed.
Mid-drain resends, configuration edits and searches: all sub-second, all confirmed live by the operator - 150 capture toggles fired twenty at a time landed 150 for 150.
A service instance was deliberately restarted mid-drain - live views reconnected on their own and capture never gapped.
In run 14 the write side was throttled at one tenant's storage ceiling for four minutes: 149,000 low-priority retries inside the pump, zero failed writes, and not one throttled operator read - which is exactly what the two priorities are for.

The before/after

On entry-tier shared storage, the same drain produced 100+ throttled reads and visible "service busy" moments. On the production shape: none - the throttling that does occur at the ceiling lands on the pump's low-priority writes, never on a person's click. That difference is engineered, not lucky, and it is why the production tier is shaped the way it is.

The zero-loss record, still unbroken

Across the entire stress-test program - fourteen published runs including deliberate saturation, storage-outage drills, instance restarts mid-drain and concurrent operator abuse - not one message has ever been lost. The capture pump writes first and acknowledges only on success; when anything downstream misbehaves, messages simply wait where Service Bus put them.

Every run ends with a ground-truth reconciliation against Service Bus - zeros on both sides or it isn't done.
A circuit breaker pauses capture during storage outages instead of spinning messages toward their delivery limits.
Duplicate-safe by design: dedupe on capture, honest refusals on double-resend.

Chaos, invited

Mid-drain we toggle capture off and on per entity, restart service instances, and resend messages while hundreds per second flow past. The worst outcome recorded so far, in run 14: the background counters fell tens of minutes behind a 105,000-message burst, and one queue showed 0 pending while it held 700. No message was touched; the number was late. The projection was rebuilt the same day - it now recomputes each queue once per round instead of once per batch, writes with a version guard, and reports how far behind it is.

Scaling that behaves like arithmetic

Cost and throughput follow published constants, not vibes: ~16 request units per captured message, confirmed across eight independent measurement runs, and ~150 messages/second of capture per one-core service instance, scaling linearly up to a measured per-tenant ceiling of about 600 per second - one storage partition's worth of writes and a Standard Service Bus namespace's throttle, which happen to coincide. That is twenty times the 30 per second a tenant is promised; a tenant that needs more gets a Premium namespace and a larger partition budget, not a redesign.

Dashboards read maintained counters, so their cost stays flat whether you store ten thousand messages or ten million - and since run 14 the counters are kept current within seconds of a burst, however many queues it touches.
Deleting an entity's entire history is a server-side operation: 21,000 messages purged for 54 request units of client cost.
Burst capacity is a runbook, not a redesign: scale the ceiling up for a spike, drain, scale back down and merge storage partitions back - rehearsed end to end in under 7 minutes at zero extra cost.

Why this matters commercially

Because the cost per message is a measured constant, we can price predictably - and you can capacity-plan with multiplication instead of load-testing our product yourself.

Wide fleets and big replays, tuned under stress

Our September stress program pushed two shapes most tools quietly fall down on: a namespace with 150 entities all dead-lettering at once, and a single-incident replay of tens of thousands of messages. Both got measured, and both got faster.

Wide-fleet capture no longer starves. The pump now sizes its in-flight work to the number of active listeners instead of a fixed budget - across a 150-queue namespace that lifted aggregate capture several-fold, draining a banked burst of 30,000+ dead-letters to zero in about four minutes; by October the same shape drained 105,000 in the same four minutes. The background counters kept pace at 30,000 and fell behind at 105,000 - the finding that led to the rebuilt projection.
Bulk resend and archive run a batch in parallel. A large replay that used to crawl at a few messages a second now clears well over fifty a second - a thousand-message replay finishes in roughly half a minute - with every duplicate guard, edit-lock and per-message outcome report intact.
Both fixes were found, fixed and re-verified against a production-shaped database in the same week, and shipped straight into the product.

Built for the estate you actually run

Real Service Bus estates are lopsided - one namespace with hundreds of entities, the next with a handful. Capture and replay both adapt to the fleet in front of them, so a big customer is not paying a throughput tax for a design tuned to a small one.

How we measure

Numbers come from Application Insights telemetry with deliberate ingestion-lag offsets, and every message count is reconciled against the Service Bus management API - the broker's own truth, not our dashboards grading their own homework. The full run-by-run history, including the runs where we found and fixed our own bugs, is in the product's stress-test record.

Production-shaped test environment: dedicated throughput tiers, authentication on, plan limits enforced.
A human operator hammers the console during every drain - latency numbers include real browsing, not synthetic pings.
Found-in-testing issues ship as fixes the same day and appear in the changelog like everything else.

Read the receipts

Prefer raw numbers to marketing pages? The stress-test documentation ships with the product and names every figure on this page, with dates and telemetry queries included.

Run the numbers on your own namespaces.

Connect a namespace and watch the capture rate, cost and latency yourself - the same telemetry we publish is built into the product. Free for 30 days.

Start free - continue with Microsoft Compare with Azure Monitor

Performance we measured, not promised