We publish our numbers.

Router ingest — routine imaging

These are ingest figures — the rate at which one router accepts a study and writes it to its spool. They are not delivery rates. Measured with realistic study-mode load — many instances per DICOM association, the way real modalities transmit — not the pessimistic one-association-per-image case that flatters a vendor's numbers.

These are single-node figures. This section and the two below it — SynthIQ memory and 3D mammography concurrency — were each measured against one instance of the product under test: a single router here, a single SynthIQ in the memory results. That was deliberate: the point was to find where one node's limits actually sit, not to publish a number inflated by a cluster. In production, capacity scales by adding nodes behind a SynthIQ pool rather than by buying a larger box, so treat these as the per-node building block. The pooled results further down — SynthIQ fronting a router pool — are the other half of that picture, measured across a two-node router pool and labelled as such.

SynthIQ fronting a router pool — dedicated cloud

August 2026, on Vultr dedicated-CPU instances in a private VPC: a 2 vCPU / 8 GB SynthIQ instance receiving DICOM and load-balancing it across a two-node XyDromatics Router pool. Every run is 20,000 synthetic CT instances at 32 concurrent senders, with every product at shipped defaults — no tuning of any kind.

These are pooled ingest rates. They measure how fast the pool accepts and spools, which is the number that tells you whether your modalities get refused at peak. Pooled delivery — the rate at which the pool clears what it accepted — has since been measured as well, on 24 August 2026, though on the Azure rig rather than this one. It is in What pooling costs on delivery below, and it is the one result in this correction that came out better than what we had been publishing.

Four clean runs, mean 537.9 instances/sec of pooled ingest. A fifth run is listed and excluded, because it is ours: at 418.7 it sat well below the other four, and we originally kept it. We had checked the wrong thing — every host showed 0.00% hypervisor steal and the balancer was at 99% CPU, so we concluded there was no fault to blame. The fault was not in the host telemetry. On that run the sender saw 19,657 of 20,007 instances acknowledged; 350 were not. Our curation rule says a run appears here only if the sender saw every instance acknowledged, and it did not. Excluding it moves this figure up, from 514.0 to 537.9 — we had been under-reporting ourselves by keeping a run we should have dropped.

These numbers replace lower ones we published earlier. The previous figures averaged 347.4 instances/sec. They were measured with a defect in our own software — an unbounded write-ahead log — and with one of the two receiving nodes left on the older build for the entire series, so pooled traffic ran through a node that degraded as it received. The improvement percentage we quoted alongside them is withdrawn: our own curation rule voids every pre-fix run, so there is no baseline left to measure an improvement against. The figures above are absolute, not relative to anything. We found this by re-checking our own rig, not because anyone challenged the numbers.

What pooling costs on delivery — and it costs less than we said

Azure figures, measured 24 August 2026 — after this correction pass had already begun, which is why this page said in three places, until now, that no such figure existed. Both routers 8 vCPU EPYC 9V74: identical silicon, so the two direct rates are comparable to each other and to the pooled one. All four Router-class hosts were reset to a clean database first, the sinks included. Published workload verbatim, three runs per condition, every run settling at exactly 20,000 delivered with zero failures.

All rates are study-instances/sec.

The ingest row is why you should believe the delivery row. It is not there for symmetry: it reproduces the 0.45 pooling ratio we already published at 8 vCPU, and it does so on the same runs that produced the delivery figure. A favourable new number that arrives on a rig which no longer reproduces the unfavourable old one is not a measurement, it is a change of subject. This one reproduces it. And the pool split the work evenly to within 1% — 10,100 / 9,900 and 10,000 / 10,000 across the two nodes — so nothing here is an artefact of a lopsided balancer.

Why the two rows disagree. Ingest is the front door, and the extra hop through the balancer costs real acceptance capacity — every object is received once by the pool and again by a router. Delivery is the pipeline, and the pipeline is where a second node actually helps: each router forwards through its own outbound leg to its own sink, so the two legs run in parallel where the single front door cannot. Measuring only the front door was hiding the benefit the pool exists to provide. The published 0.45 understates what a pool is worth; it is a true ingest ratio and a misleading summary of pooling.

What this is not: a delivery figure for any other pool size, cloud or workload. It is one tier — 8 vCPU — on one rig. The pooled ingest ratios of 0.36 / 0.43 / 0.45 further down remain ingest ratios and are not restated by this result, and we are not going to interpolate a delivery curve through a single point.

Does a bigger load balancer help?

Azure figures. Only that rig answers this question: every Azure node runs the same processor model, so 2 → 4 → 8 vCPU changes core count and nothing else. Our Vultr rig mixes EPYC-Rome and EPYC-Milan across tiers, so its curve cannot separate core count from processor generation.

Up to a point, and then it stops. Quadrupling the load balancer from 2 to 8 vCPU buys 25% of ingest, and most of that arrives by 4 vCPU. Past there the constraint moves off the balancer and onto the routers behind it — measured directly: at 2 vCPU the balancer runs at 97% CPU while the routers sit at 73–76%; at 8 vCPU the balancer drops to 28% and the routers become the busiest thing in the path.

Only one of our two rigs is quoted here. The other mixes AMD EPYC-Rome and EPYC-Milan processors across its tiers, so its curve varies core count and processor generation at the same time and cannot answer this question — however reasonable its numbers look. The rig quoted runs an identical processor on every node.

The August 2026 ingest-versus-delivery correction does not disturb this comparison. Every figure in it is an ingest rate, on both sides of every ratio, measured the same way — so the shape of the curve, and the conclusion that the constraint moves off the balancer by 4 vCPU, stand as measured. Only the column heading needed the word ingest. What the curve does not tell you is how the pool's delivery rate scales with balancer size. We now have pooled delivery at one tier only — 8 vCPU, in the section above — and one point is not a curve.

Where the router stops accepting images

Every store-and-forward router has a volume at which its operational database becomes the limit. We measured ours rather than leaving you to find it: eight sustained soaks, four per cloud, each pushed until the router began refusing images.

The two clouds differ by 3% while runs on the same cloud vary by up to 33% — so the limit is a property of the software, not of the hardware you run it on, and it travels. That is the opposite of the rate figures above, which are firmly a property of your hardware. Both are worth knowing, for different reasons.

This one is unaffected by the ingest-versus-delivery correction above, because it is not a rate at all. It is a database size at the moment the router first refused an image — a threshold, measured in megabytes, on a clock-independent event.

Two things follow that we would rather say plainly. There is no gradual warning: ingest held between 66% and 103% of baseline right up to the burst in which refusals began — one run was measurably faster than its own baseline as it hit the wall. And the fix is retention, not a bigger disk. A retention policy that deletes nothing under load fails the same way on any database engine, just later.

The routers behind the pool, measured individually — ingest and delivery

This section previously described these figures as real end-to-end work: receive, write to spool, evaluate routing rules, forward by C-STORE to a live destination that drains. Three of those four stages were in the measurement. The fourth was not. The harness stops its clock at the sender's C-STORE response, and the router answers success as soon as it has taken the object onto its processing queue — forwarding runs asynchronously behind that queue, after the stopwatch has stopped. The 527 and 817 we published were ingest.

We re-measured both boxes on 24 August 2026, running the published workload verbatim — 15-second ramp, 500-instance warmup, 32 concurrent senders — three times per host, on a clean database, with the queues verified empty at settle and no failures in any run. Ingest reproduced the published figures. Delivery, counted as the objects the receiving node actually acknowledged and clocked from first arrival to last delivery, is the second number in the table below. Both hosts are the same cloud plan; the silicon we were actually given differs, which is exactly why we quote the clock with every figure rather than the plan name.

What the destination was, because it changes how you should read these numbers. Each router forwarded to a separate receiving node that accepted and wrote every object — four nodes per cloud, in two fixed pairs, rather than two hosts trading roles. The receiving nodes are not clones of the routers: on Vultr they carry 15 GB against the routers' 62 GB, and on both clouds they run at a lower clock. They were sized to drain without becoming the constraint, not to mirror the sender. That choice matters, and the alternatives we rejected show why. With a discard rule and no writes at all the same host reported 1,653/sec. With no reachable destination it reported 501/sec — back-pressured, its outbound queue simply filling.

We used to say the draining configuration was the one that “measures the product doing its actual job.” That claim is withdrawn. All three of those figures are acceptance rates — the same clock, stopped at the same place. What the spread between them actually shows is that acceptance is coupled to the state of the outbound queue: back-pressure downstream slows the front door. That is a real and useful property, and it is why we still publish the draining configuration rather than the discard one. But a number that moves with downstream conditions is not thereby a measurement of the forward. The forward is the delivery column, and it took a separate measurement to get it.

The consequence, stated plainly: a router sink is a cheap drain. It writes no archive catalog row to a database per object. Point the same router at a real archive on a relational database and expect the archive, not the router, to become the first thing that saturates. These are router figures, not whole-system figures — and that applies to the delivery column as much as the ingest one. Delivery against a cheap sink is the ceiling, not the expectation.

Ranges are the spread across three runs per host. The CPU column is from the original ingest campaign. Read the two rate columns as a pair: the Rome box accepts at 511/sec and clears at 159/sec, the Milan box accepts at 751/sec and clears at 196/sec. At the instant the published clock stopped, 8.0% of the workload had been delivered on the Rome box and 2.0% on the Milan box; the rest was still in the queue.

One control run, reported because it is interesting and flagged because it is not a configuration you would deploy. On an Azure host — 8 vCPU EPYC 9V74 — with the spool placed on a RAM-backed filesystem rather than disk, delivery measured 336 instances/sec (four runs, 329–351) at association caps of 40/40/40, and 321/sec (three runs, 316–329) at caps of 32/10/3. The forwarding leg alone ran at 524 and 480/sec respectively, against ingest of roughly 724–755/sec; 19.4% of the workload had been delivered when the send-loop clock stopped. We ran it to see how much of the delivery gap is spool I/O. It is a deliberate control with the durability taken out, not a customer configuration, and we are not quoting it as a product figure.

Method: DOC-2026-490, the same controlled test method as every other figure on this page, with the delivery measurement added 24 August 2026. Raw harness output, the per-instance delivery counts and per-second CPU samples for each run are retained and available with the method on request. This campaign is one location of a planned multi-site series — the same rig, workload and method repeated on other clouds and on physical hardware, published here as each completes.

How we measured

The rig

One VM generated DICOM load; a separate VM ran the system under test — a single router instance, not a pool — and they communicated over a private network with nothing else competing for resources. The system under test was measured at three host sizes — 4 vCPU / 16 GB, 4 vCPU / 32 GB and 8 vCPU / 64 GB — so the limits could be watched moving with the box rather than read from a single data point. Generator utilisation was recorded alongside every result, so a figure is only reported where the generator was demonstrably idle and the constraint was genuinely in the system under test.

The corpus

Synthetic DICOM throughout — no patient data of any kind. The harness emits studies from five modality emitters (CT, MR, CR, US and MG) rather than replaying a clinical archive, which is what makes the corpus profile publishable and the runs repeatable. The stress cases are deliberately the two opposite shapes: few enormous multi-frame objects (tomosynthesis) and very many small objects (a 10,000-slice CT).

The harness

A self-contained .NET 8 console application. It provisions its own sources, destinations and routing rules; emits the synthetic studies through the product under test; sweeps a rate ladder recording p50 / p95 / p99 latency; and tears down everything it created on exit. Production wiring is never touched — only the artifacts the harness itself created are removed.

What the harness actually records, stated plainly: it counts sender-side C-STORE successes and divides by the elapsed time of the send loop. That is the number, and it is the only timing mode either harness has. Because the router returns success as soon as it has queued an object for processing, this clock measures ingest. It stops before forwarding completes.

The delivery figures were produced separately and by a different count: the objects present in the receiving node's sent/ directory — one file per instance the router forwarded and the sink acknowledged — clocked from first arrival to last delivery, with the queues verified empty at settle before the run was accepted. Three runs per host, on a database reset to empty beforehand.

If you are evaluating us and want to run it in your own environment against your own hardware, ask — we would rather you measured us than took our word for it.

A variable we did not control

Router ingest declines as its operational database grows — that is the volume limit measured further up this page, and it is the one condition on this rig capable of moving a rate without anyone touching the workload. Our soak script knows this and handles it: it resets the operational database before each measurement, and says why in its own comments — the sink is itself a router and accumulates as it receives, so leaving it loaded would mean the measurement degrading for a reason that is not the variable under test.

The campaign scripts that produced every published figure on this page do not do that. They never reset the database and never record its size. And every host on both rigs was found above the lowest database size at which we measured a refusal (438 MB) — the two busiest far above the top of that range, at 1,467 MB on the Rome router and 1,901 MB on one of the sinks. So the published figures were taken at an unknown and drifting database volume, on a variable we had already demonstrated matters. We are disclosing it rather than restating the figures, because we do not know the size at each run and will not reconstruct one. The 24 August delivery measurements were taken on a clean database; the ingest figures beside them were not.

What we have not measured

Delivery, on most of this page. It has been measured on exactly two single hosts — the two Vultr routers in the table above — on a two-node Azure pool at one balancer tier, and on one deliberate control on Azure with the spool on a RAM-backed filesystem. It has not been measured for either host in the routine-imaging table, for the 3D mammography concurrency ladder, or at more than that single point on the load-balancer scaling curve. Every rate in those places is ingest. We are not going to derive a delivery figure for them from the handful we have; the ratio between ingest and delivery already differs by processor generation on the only two hosts where we can compare, which is reason enough not to extrapolate it onto a third.

End-to-end AI-vendor egress latency — the added round trip through the cloud routing tier to an AI vendor and back — has not yet been measured and published. The design target is <200 ms p99 added latency for radiology-report-sized payloads, but a target is not a measurement and we will not quote it as one. It appears here when the run is done.

The pool scaling factor — pooled ingest divided by the sum of the same routers' ingest measured individually — is now published: it is Figure 2 above, and it runs 36% / 43% / 45% across the three Azure tiers. Both sides of that ratio are ingest rates measured the same way, so the ratio holds; what it does not describe is the pooling cost on delivery. That is a separate measurement, now made at the 8 vCPU tier and reported under What pooling costs on delivery above, where the pool comes out at 0.65 on delivery against 0.45 on ingest — cheaper on the pipeline than at the front door, and not a figure the ingest ratio could have stood in for. Getting there found a bottleneck on our side rather than a limit of pooling: the pool tier was opening a new DICOM association for every single image it forwarded, instead of reusing one across many. Each router was paying the full cost of setting up a connection per image and spending its processor on handshakes rather than on images.

We have fixed it, and the figure gets published once the run is repeated against the corrected build. We are saying this here rather than quietly republishing a better number later, because a benchmark page that only ever reports flattering results is not measurement, it is advertising — and the first thing this campaign measured carefully turned out to be a defect of our own.