Right-sizing DICOM routing for mammography.

Executive summary

Sizing a DICOM router is usually guesswork: a vendor quotes "enterprise-grade hardware," a hospital over-buys storage it never uses, and nobody can say what actually happens when four mammography units start pushing 3D tomosynthesis studies at once.

We took a different approach. On a dedicated performance rig — an isolated DICOM generator driving a system-under-test across three host sizes — we measured exactly what governs XyDromatics Router capacity. The findings are clear, and a few are counter-intuitive:

• Routine imaging is storage-bound, and cores do not move it. Measured on real 512 KB CT instances (shipping build, spool on ext4, six replicates): ~155 instances/sec at 2, 4 and 8 vCPU alike — 4→8 vCPU scaling of 1.00×. On the same host, moving that spool to a RAM filesystem took ingest to 849 instances/sec — 6.50× — so the spool volume’s write path is the ceiling. The ~700/~1,500 figures previously headlined here are real retained measurements — of 1 KB test objects, roughly 500× smaller than the CT instances this page discusses; they were mislabeled as study-instances/sec and are re-scoped in §4.
• Ingest is not delivery — size on delivery. A router answers the modality as soon as it has spooled the object; forwarding runs behind that queue. On the two 8 vCPU hosts where we measured delivery directly, the same workload delivered at 159 and 196 instances/sec against ingest of 511 and 751 — 3.2× and 3.8× lower (§4.1). On a disk-backed spool the two clocks converge instead (measured 1.09× on ext4, §4.1) — so an ingest rate overstates capacity roughly threefold on a RAM-backed spool, and barely at all when real storage gates both legs.
• Provision storage write bandwidth, not IOPS. The June finding that quadrupling IOPS changed nothing was an ingest-side observation and survives — but it was read as “disk speed is irrelevant,” and that reading is wrong. For delivery, the spool volume’s sustained small-file fsync bandwidth is precisely the limit (§4): a datasheet IOPS number does not predict it, a measured fsync throughput does.
• 3D mammography’s memory use scales with the host, by design. The 75% heap ceiling adapts: the same 16-volume workload peaked at ~11 GB under a 16 GB cap, 21–24 GB under 32 GB, and 41–43 GB uncapped on 62 GB — accepted in full at every tier, with latency (not refusals) as the cost of a smaller box in our re-measured runs (§5).
• High memory use under load is by design, not distress — now confirmed by direct measurement. The router’s runtime is configured with a hard heap ceiling at 75% of host RAM; the heap grows toward that ceiling and recovers afterward. Removing the cap on a 62 GB host nearly doubled peak use (21.7→41.2 GB at the same load), proving the ceiling was what bounded it (§5–§6).
• Capacity grows by adding nodes, not bigger boxes — measurably, though not linearly. A SynthIQ pool load-balances across routers and places large studies on nodes with memory to spare; two nodes delivered 432 instances/sec against 350 for one, and 0.65 of the two measured separately (§7).

The result is a sizing matrix you can buy against with confidence — with the rate expectations stated as delivery rather than ingest — and a scale-out trigger that tells you exactly when to add the next node.

§2 — Methodology

Credibility here comes from rigor, so the method matters.

• Dedicated rig, isolated roles. One VM generated DICOM load; a separate VM ran the router under test; they communicated over a private network. Nothing else competed for resources.
• Three host sizes. The system-under-test was measured at 4 vCPU / 16 GB, 4 vCPU / 32 GB, and 8 vCPU / 64 GB — so we could see how the limits move with the box, not just read one data point.
• Realistic send patterns. Routine load used study-mode — many images per DICOM association, the way real modalities transmit — not the pessimistic one-association-per-image worst case.
• Dual-host attribution. Every high-load run sampled CPU on both the generator and the router. This is the discipline that makes the conclusions trustworthy: when 3D mammography began failing at high concurrency, the naïve reading was "the router is overloaded." The data confirmed it on a corrected reading — and showed the generator was idle while the router was CPU-saturated.
• What the throughput clock measures. Our load harnesses compute a rate as sender-side C-STORE successes divided by the elapsed send loop. A router returns success as soon as it has handed the object to its processing queue; the forward to the destination runs asynchronously behind that queue. The stopwatch therefore stops well before delivery, and every rate produced this way is an ingest acceptance rate. Delivery has to be counted on the receiving side against its own clock — §4.1.

§4 — Routine imaging: the storage write path sets the ceiling

These are ingest-acceptance rates — what the front door accepts and spools, which is the clock this section is about. What the router then delivers downstream is a separate measurement, in §4.1 below. Re-measured 2026-08-25 on real 512 KB CT instances — shipping build, spool on ext4, CPU affinity verified on every tier, six replicates (RI-2026-644, retained evidence bundle):

Doubling cores twice changed nothing — 4→8 vCPU scaling is 1.00×. What does move the number is the storage underneath it. On the same host and the same build, moving the spool from ext4 to a RAM-backed filesystem took ingest from 130.6 to 849.1 instances/sec — 6.50×. Across every host and medium measured the sustained rate spans 67 MB/s to 450 MB/s, entirely on what the spool writes to. Cores cannot matter when the disk is the wall.

A withdrawn figure, then measured. An earlier version of this section stated that the volume delivered 80 MB/s for fsync-per-file writes against 169 MB/s raw sequential, and that the router therefore ran at “97–98% of the storage ceiling”. Those figures existed nowhere in the evidence corpus as a measurement — no conditions record, no command line, no replicate count, no output file — so they were withdrawn on that basis. The device has since been measured properly, across three replicates.

The raw-sequential figure came back at 168.7 MB/s against a withdrawn claim of 169 — it was right, and had simply never been retained. The fsync figure was close too, and should still not have been quoted, because it is not a device constant: the cost is per file rather than per byte, at 5.6–7.0 ms per durable write at either size, so megabytes per second scales with object size and one number cannot describe it.

The ratio was unsound for a separate reason, which measurement now quantifies. It divided bytes on the wire by bytes on the disk; the router’s write amplification is 2.22× — 1,184 KB reaches the block device per 522 KiB object once database, WAL and index writes are counted — so the two quantities were never comparable. In the unit where both sides are durable writes it is a real number: the router sustains about 159 object-writes per second where the device manages 168–178, or 89–94%, while writing 2.22× the object bytes per write. The original 97–98% was in the right neighbourhood, for the wrong reason and in the wrong unit.

What happened to ~700 and ~1,500 instances/sec? An earlier version of this page reported those figures and later said their raw data had not been retained. Both statements were wrong in instructive ways. The data was retained — in a June results tree nobody re-checked — and the runs are real: 36,000 of 36,000 objects at 1,500.7/sec. But the retained run records pixel_bytes: 1024 — one-kilobyte test objects, roughly 500× smaller than the CT instances the rest of this page discusses, published under a label (“study-instances/sec”) that implied otherwise. At one kilobyte an object the spool write path is nowhere near saturated, so the association-cap and CPU effects the June notes describe are what remains visible — which is how a cores-scale-linearly narrative could be honestly measured and still be wrong for real imaging. The August figures above, on real image objects rather than kilobyte placeholders, are the ones to size from.

One June observation does survive at every object size: more connections aren’t faster. Throughput peaks at moderate concurrency; a client that opens far more simultaneous associations than the configured cap just queues the excess. A client-tuning consideration, not a hardware limit.

4.1 Ingest is not delivery

The figures above are what the front door accepts. They are not what the router delivers. A router answers the modality with success as soon as it has handed the object to its processing queue; the forward to the destination runs asynchronously behind that queue, and the harness clock stops at the last sender-side response. Everything the router has accepted but not yet forwarded is still sitting in that queue when the number is taken.

In August 2026 we measured delivery directly for the first time, counting on the receiving side: one instance per object the router forwarded and the sink acknowledged, clocked from first arrival to last delivery, on a clean database with the queues verified empty at settle. Three runs per host, zero failures, the published workload unchanged (15-second ramp, 500-instance warm-up, 32 concurrent senders).

Two different ratios live around this table; they are not interchangeable. The last column is the product's own ingest-to-delivery relationship — the re-measured ingest divided by the delivery beside it, 3.21× and 3.83×. The separate question of how far our previously published figures overstated delivery uses those published figures as the numerator instead: 527 against 159 is 3.31×, and 817 against 196 is 4.17×. The first pair describes the product; the second pair describes the size of the error a reader of the old page was handed. We state which is which wherever either appears.

Put the other way round: at the moment the ingest clock stops, 8.0% of the work has been delivered on the Rome host and 2.0% on the Milan host. The rest is queued.

The forwarding leg does not scale with the processor the way the front door does. Those two hosts have the same core count and differ in processor generation and clock. At the front door they are far apart — 751/sec against 511 — and on delivery only 1.23× apart, 196 against 159. Buying a faster processor moves the front door far more than it moves the forward — the opposite of what an ingest-only measurement would lead you to expect. (An earlier revision of this paragraph put the ingest gap at 1.63×, a multiple carried over from a working note that does not divide out of the measured means. It has been removed rather than replaced with a recomputed one; the means themselves are quoted instead.)

For reference, a deliberate control — the same workload on an 8 vCPU Azure host with the spool on tmpfs, which is not a customer configuration — delivered 336/sec at association caps of 40/40/40 (four runs, 329–351) and 321/sec at caps of 32/10/3 (three runs, 316–329), with the forwarding leg measured on its own at 524 and 480/sec. Ingest on that host ran ~724–755/sec, so even with the spool in RAM the delivered fraction at the moment the ingest clock stops was 19.4%.

These delivery runs were made on the cloud rigs of DOC-2026-490. How the §4 ladder relates to them is now measured directly, on the ext4 host itself: ingest 154.5/sec against delivery 141.2/sec — a ratio of 1.09× (two replicates, both reconciling exactly at 20,000 instances, zero refusals). With the spool in RAM the same ratio is 3.21× and 3.83× on the two cloud rigs. When storage binds, the two clocks converge — the same device gates both legs — so a site whose spool is on disk can size from either figure. A site whose spool is in RAM cannot: there, an ingest number overstates delivery roughly threefold. As a cross-cloud sanity check, the two delivery figures on comparable 8 vCPU silicon — 141.2 on Azure ext4 and 159 on the RAM-spool Rome host — agree within 11%.

§6 — "Why is the router using most of my RAM?"

Under 3D load, the router's memory footprint rises toward ~75% of host RAM — even at light concurrency. This is intentional, and it is now directly measured: the runtime is configured with a hard heap ceiling at 75% of host RAM, and the server garbage collector trades memory for throughput by letting the heap grow to that ceiling before reclaiming. The footprint reflects allocation high-water plus not-yet-collected scratch memory, not the live working set (which is far smaller — capping the same host at half the RAM ran the same workload in half the memory, with nothing refused). It recovers fully after a burst.

The practical guidance: high memory use is healthy as long as the node isn't shedding, and you should not co-locate other memory-hungry services on a mammography router — it will use the RAM you provision for it, by design.

§8 — Recommended configurations

• 32 GB is the floor for 561 MB-class tomosynthesis — a deliberately conservative figure: re-measured, a 32 GB ceiling ran 16 concurrent volumes with nothing refused, at higher latency (§5.2).
• 64 GB / 8 vCPU is the recommended mammography spec — clearing the memory regime and providing the cores that then become the limit.
• Size the spool volume by measured write bandwidth, not IOPS. Routine-imaging throughput tracks the spool medium and nothing else: on one host, swapping ext4 for a RAM filesystem moved it 6.5× while quadrupling the cores moved it under 1%. A volume’s IOPS rating does not predict fsync-per-file bandwidth; measure your own volume, or ask us to.
• Beyond a single node's band, add a SynthIQ pool node.

Size against delivery, not ingest. This table says which resource runs out first — cores for routine imaging, memory-then-cores for 3D mammography. It does not carry a studies-per-hour promise, and any such promise derived from the ingest rates in §4 would over-state a site's real capacity by roughly threefold. The delivery figures in §4.1 — 159 and 196 instances/sec on the two 8 vCPU hosts we measured — are the ones to plan against, and for a two-node pool the measured delivered figure is in §7. We have not measured delivery on the 4 vCPU / 16 GB or 8 vCPU / 64 GB configurations above and will not extrapolate it; ask for a sizing run against your own modality mix instead.