Owned measured evidence
RabbitMQ load testing: an owned HTTP-to-completion experiment
Measured 2026-10-03 by LoadStrike (Meticulis). Presentation assisted by AI.
An owned engineering workload matched all 28,800 measured attempts across 18 repetitions, with zero SDK failures and zero distinct measured timeout IDs. Results use native HTTP plus a public DelegateStream completion observer; they are specific to this workload and shared machine.
Workload: each POST carries a unique correlation ID and 1,024-byte UTF-8 payload. A worker performs 20,000 successive SHA-256 hashes, confirms outcome publication, then acknowledges the work message.
System: a native HTTP source calls an owned API that confirms work publication to real RabbitMQ before returning HTTP 202. A RabbitMQ.Client 6.8.1 asynchronous consumer supplies correlated completion observations through the public DelegateStream integration.
Scenario: one invocation produces one work item and one correlated completion outcome. One or four workers use prefetch 1 and manual acknowledgements; outcomes are reconciled against independent application and observer logs.
Load: configured Inject demand is 5, 10 or 25 invocations per second for 120 seconds, with three repetitions of each worker/rate condition. Each repetition has a 30-second sequential unpaced warm-up and a fresh fixture with reset queues.
Runtime: published LoadStrike 1.0.33401, RabbitMQ.Client 6.8.1, .NET runtime 8.0.10 / SDK 8.0.403 and RabbitMQ 3.13.7. Reproduction requires a legitimate eligible runner entitlement; no runner key is included.
Topology: a shared Windows host with 12 logical processors and approximately 31.8 GiB RAM, with Docker Desktop exposing 12 CPUs and approximately 15.5 GiB RAM. Existing services, browser checks and research also used this host. This experiment does not measure a distributed LoadStrike cluster.
This owned engineering experiment uses the normal licensed published LoadStrike SDK with native HTTP and a public DelegateStream observer backed by RabbitMQ.Client. The native RabbitMQ destination smoke accepted and processed ten outcomes but observed no destination delivery: all ten SDK attempts timed out. That failed smoke is retained separately. The measured matrix below uses the delegate integration and does not validate the native RabbitMQ destination adapter.
Observed completion latency spans the SDK HTTP source timestamp to the observer-supplied completion timestamp. It differs from time to HTTP 202, worker-local processing, broker latency and browser Web Vitals. p95 is a nearest-rank percentile over matched load-phase samples; timeout IDs are reported separately and may be a subset of failures.
The load cohort is inferred from the chronological suffix of unique source IDs sized to the SDK load-phase request count, then reconciled with independent accepted, processed and observed outcomes. Raw rows have no per-ID phase marker. Sequential warm-up finishes before injection. Earlier native and fixture failures are retained separately from the corrected fresh matrix.
This shared Windows machine with Docker Desktop is not an isolated rig. The table is ordered numerically by worker count, offered rate and repeat. Actual execution order is deterministic and recorded in the full report, along with resource sampling and other activity limits. Configured offered rate is demand, not achieved maximum capacity, and these results do not establish competitor superiority or a customer outcome.
