# Owned transaction completion experiment — 3 October 2026

Status: **18/18 planned runs have retained results**. Full batch complete: True. Independent reconciliation checks pass for completed runs: True.

This is a reproducible, owned engineering case experiment: a C# HTTP API enqueues work in RabbitMQ, workers compute a fixed digest, and LoadStrike correlates the initiating request with an observed completion. It is not a customer case study, competitor comparison, native RabbitMQ adapter validation or maximum capacity measurement.

## What actually ran

The pinned public LoadStrike 1.0.33401 SDK used its normal runner entitlement, native HTTP source and public DelegateStream destination. The owned completion observer used RabbitMQ.Client 6.8.1 with async dispatch enabled. No SDK changes, licensing overrides, paid infrastructure or synthetic observations were used.

Each POST carried a fresh GUID in X-Correlation-Id and 1,024 UTF-8 payload bytes. The API confirmed publication to the work queue and returned HTTP 202. Each worker used prefetch 1, computed 20,000 successive SHA-256 hashes, logged the independent outcome, confirmed completion publication and acknowledged work. The observer supplied its own delivery-observation timestamp and acknowledged completion after invoking the SDK callback. The hash is independently recomputed by the analysis script.

One and four workers were exercised at configured injection rates of 5, 10 and 25 invocations/second, with three repetitions per condition. Each run used a 30-second sequential, unpaced warm-up followed by 120 seconds of configured injection. Queues were reset and the fixture restarted between repetitions. Run order was one worker before four, rate ascending, repetition ascending. All repetitions are shown below.

The shared Windows host has 12 logical CPUs and 34,130,661,376 physical memory bytes (~31.8 GiB); the Docker VM exposes 12 CPUs and 16,654,741,504 memory bytes (~15.5 GiB). The broker had no explicit CPU/memory limit. Shared Windows laptop. Existing Docker services, later focused header-browser checks, ordinary browser research and concurrent agent analysis/verification shared the host. Earlier broad website checks finished before this restart. Host activity was not controlled; no isolated-hardware, causal worker-count or capacity claim. This restarted matrix uses corrected async publisher admission for every repetition. This is not a controlled causal comparison of worker count.

## Load-phase results

Raw correlation rows include warm-up and have no per-ID phase flag. The verified SDK executes sequential warm-up completely before injection. Analysis selects the final chronological unique source-ID cohort, sized to each scenario's load-phase request count, then reconciles it against SDK matches, independent accepted/processed/observed IDs and timestamps. This is disclosed phase inference, not an invented phase observation. Any ambiguous or failing cohort requires manual review. Warm-up counts are retained separately in analysis.json.

Latency here means the native HTTP source timestamp before sending to the DelegateStream completion-observation timestamp on the same machine. It includes application/broker/observation effects; it is distinct from server acceptance duration and worker-local duration. P50/P95/P99 use nearest-rank percentiles over the matched load cohort and the SDK's reported millisecond samples. Timeouts are reported separately and are not latency samples.

| Workers | Offered/s | Repeat | Requests | Matches | Failures | Timeouts | P50 ms | P95 ms | P99 ms | Server acceptance P95 ms | Worker local P95 ms |
|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| 1 | 5 | 1 | 600 | 600 | 0 | 0 | 50.666 | 234.268 | 450.769 | 85.880 | 22.914 |
| 1 | 5 | 2 | 600 | 600 | 0 | 0 | 50.656 | 121.914 | 188.924 | 16.186 | 23.182 |
| 1 | 5 | 3 | 600 | 600 | 0 | 0 | 44.176 | 91.424 | 133.806 | 11.734 | 18.578 |
| 1 | 10 | 1 | 1200 | 1200 | 0 | 0 | 77.337 | 155.744 | 198.398 | 19.074 | 16.781 |
| 1 | 10 | 2 | 1200 | 1200 | 0 | 0 | 82.808 | 185.897 | 234.042 | 22.244 | 18.274 |
| 1 | 10 | 3 | 1200 | 1200 | 0 | 0 | 73.151 | 137.642 | 167.236 | 17.443 | 14.557 |
| 1 | 25 | 1 | 3000 | 3000 | 0 | 0 | 173.448 | 341.459 | 417.195 | 40.770 | 14.996 |
| 1 | 25 | 2 | 3000 | 3000 | 0 | 0 | 199.970 | 414.498 | 535.765 | 57.126 | 17.118 |
| 1 | 25 | 3 | 3000 | 3000 | 0 | 0 | 171.370 | 343.325 | 449.158 | 42.215 | 14.926 |
| 4 | 5 | 1 | 600 | 600 | 0 | 0 | 24.518 | 41.583 | 54.914 | 10.748 | 22.576 |
| 4 | 5 | 2 | 600 | 600 | 0 | 0 | 25.163 | 41.520 | 51.998 | 10.587 | 20.627 |
| 4 | 5 | 3 | 600 | 600 | 0 | 0 | 26.439 | 46.358 | 61.770 | 11.366 | 21.914 |
| 4 | 10 | 1 | 1200 | 1200 | 0 | 0 | 40.099 | 93.646 | 206.331 | 44.771 | 22.375 |
| 4 | 10 | 2 | 1200 | 1200 | 0 | 0 | 39.106 | 64.215 | 74.788 | 20.869 | 20.609 |
| 4 | 10 | 3 | 1200 | 1200 | 0 | 0 | 38.213 | 60.693 | 74.192 | 17.462 | 19.161 |
| 4 | 25 | 1 | 3000 | 3000 | 0 | 0 | 79.832 | 140.559 | 173.610 | 53.842 | 20.750 |
| 4 | 25 | 2 | 3000 | 3000 | 0 | 0 | 75.966 | 131.957 | 153.908 | 42.313 | 19.798 |
| 4 | 25 | 3 | 3000 | 3000 | 0 | 0 | 74.664 | 133.541 | 157.832 | 45.528 | 20.048 |

Configured demand is not a capacity result. Each successful measured cohort has its independently processed count divided by 120 seconds in analysis.json; that cohort ratio does not establish sustained throughput beyond this workload or a general RabbitMQ limit. Any drain/backlog, warnings, unmatched messages or duplicate outcomes remain part of the evidence.

## Native adapter failure retained

The initial licensed native RabbitMQ destination smoke accepted and independently processed ten requests but observed no destination deliveries: ten SDK attempts timed out, with ten completion messages still queued after drain. It also emitted eleven timeout rows for ten unique IDs, so raw row count must not be treated as unique request count. No missing-latency zero gauge was interpreted as a zero-millisecond measurement.

A separate owned RabbitMQ.Client 6.8.1 probe used AsyncEventingBasicConsumer with the default synchronous dispatcher: no delivery callback ran and two callback InvalidOperationException messages said 'Should never be called.' Enabling DispatchConsumersAsync observed delivery with no callback errors. This owned client probe does not establish the internal cause of the SDK's native smoke failure. The matrix uses the public delegate integration, and no native SDK fix was made or claimed.

The delegate-backed licensed smoke subsequently matched 10/10 attempts, independently processed all ten, and drained both queues. These two smokes are separate from the matrix; the failed native smoke was not discarded or replaced.

## Owned fixture correction and preserved earlier batch

The first matrix used synchronous lock admission around its single confirmed publisher. Six lower-rate repetitions completed cleanly; two 25/sec repetitions failed and a third was interrupted for diagnosis. No pre/post-correction results are combined. Logging-only and ordinary concurrent HttpClient probes reproduced target failures without LoadStrike: publisher-confirm IOException('Timed out waiting for acks'), subsequent closed-channel errors and truncated request-body errors. Replacing admission with SemaphoreSlim.WaitAsync retained serialization and publisher confirmations while avoiding blocked waiters. The same ordinary concurrency probe then accepted and processed 25/25 requests, and the normal licensed 25/sec probe matched 375/375 load attempts with clean independent outcome reconciliation. All earlier failures and partial data remain separate evidence. The exact thread scheduling mechanism was not independently profiled.

## Reconciliation and resources

Completed load-phase attempts: 28800; matched attempts: 28800; failed attempts: 0. Independent all-phase accepted outcomes: 65005; processed outcomes: 65005. All hash and ID reconciliation details, duplicates, missing outcomes, warnings and queue snapshots are in analysis.json.

Resource snapshots cover warm-up and load and are approximate: Docker collection time plus a one-second delay. Process CPU seconds are cumulative; the derived percentage divides adjacent CPU deltas by elapsed wall time and twelve logical CPUs. Docker CPU percentage uses Docker's convention and must not be directly compared with that Windows host-normalized process percentage. Working-set peaks and broker samples are recorded per run; they are not a complete host saturation assessment. No independent client-only HTTP latency distribution or whole-host CPU pressure was recorded.

## Reproduce and inspect

Use the included source, locked dependencies, Compose file and Run-Experiment.ps1. Supply an existing legitimate entitled runner key securely in the process environment, run the ten-attempt smoke first, then the matrix. Keep all result directories. Analysis uses Python standard library only. The experiment manifest identifies workload/source hashes, exact image digest and environment. Raw evidence retains SDK JSON and native reports, configuration, application/observer logs, runner logs, resource samples and queue snapshots. The normal services created by the runner are stopped and removed in its finally block.

Relevant product documentation: [transaction model](https://loadstrike.com/docs/concepts/what-is-a-transaction), [tracking selectors](https://loadstrike.com/docs/configuration/tracking), [public delegate stream integration](https://loadstrike.com/docs/endpoints/delegate-stream), [correlation controls](https://loadstrike.com/docs/configuration/correlation-runtime-controls). The RabbitMQ.Client dispatcher behavior can be checked in its [6.8.1 primary source](https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/v6.8.1/projects/RabbitMQ.Client/client/impl/ConcurrentConsumerDispatcher.cs).