LOAD-06Soak test (90 minutes)

Pass

No memory growth: over the last 30 minutes the server working set changed by 8.12 MB/h and the client by 9.41 MB/h, and there were no errors. The server's OS handle count kept rising slowly (807 at the start, 1,458 after 90 minutes, 151 per hour over the last 30 minutes) and a full garbage collection did not lower it; a handle census showed the growth is in Event handles (+471 in 12 minutes with the full mix, +102 with DicomServer alone and no web server). It is not caused by opening associations (6,000 short associations left the count flat), and it is not a DicomKit leak: two heap dumps of a 40-minute DICOM-only soak, 30 minutes apart, show every DicomKit and socket object count unchanged, while the extra Event and Thread handles match thread-pool worker threads that had exited and were waiting for the .NET runtime's periodic dead-thread cleanup (+17 dead workers, +19 thread handles, +46 event handles); by the end of that run the count had come back down.

What this test proves

Shows whether memory, handles or threads grow over continuous mixed use.

How it was run

1. One server process runs a DicomServer and a DICOMweb app; 16 workers run for 90 minutes: 4 C-STORE, 4 C-FIND, 4 WADO-RS and 4 STOW-RS, with a 5 ms pause after each operation.
2. C-STORE and C-FIND connections are reopened every 100 and 200 operations.
3. Working set, managed heap, handles and threads of both processes are sampled every second; growth is the least-squares slope over the last 30 minutes.
4. Follow-up runs on the same build (12-25 minutes each) split the load into DICOM-only and DICOMweb-only and counted the server's handles by type; a further DICOM-only run took two heap dumps 30 minutes apart to find which objects own the extra handles.

How correctness was checked

Every C-FIND returned exactly 20 matches, every WADO-RS image had the right size, every C-STORE and STOW-RS was confirmed.

Measured results

Latency is per operation (p50 = median, p95/p99 = 95th/99th percentile). Memory is the peak working set of the test process.

Memory over time

Start 580 MB, peak 836 MB, end 786 MB; trend over the last 30 minutes 8.12 MB per hour. No memory growth: over the last 30 minutes the server working set changed by 8.12 MB/h and the client by 9.41 MB/h, and there were no errors. The server's OS handle count kept rising slowly (807 at the start, 1,458 after 90 minutes, 151 per hour over the last 30 minutes) and a full garbage collection did not lower it; a handle census showed the growth is in Event handles (+471 in 12 minutes with the full mix, +102 with DicomServer alone and no web server). It is not caused by opening associations (6,000 short associations left the count flat), and it is not a DicomKit leak: two heap dumps of a 40-minute DICOM-only soak, 30 minutes apart, show every DicomKit and socket object count unchanged, while the extra Event and Thread handles match thread-pool worker threads that had exited and were waiting for the .NET runtime's periodic dead-thread cleanup (+17 dead workers, +19 thread handles, +46 event handles); by the end of that run the count had come back down. Working-set figures are for the server process; the client stayed between about 126 and 156 MB.

Test run

Run

a20bedea-bacd-468b-af8d-945829c4b81f

Started (UTC)

2026-10-26 17:02:46, finished 2026-10-26 18:52:45

Test PC

Intel(R) Core(TM) i9-14900K, 24 cores / 32 threads, 64 GB RAM, NVMe SSD, Microsoft Windows 11 Pro build 26200.9711, .NET 10.0.12 (one PC, client and server on loopback)

License

Enterprise

Source commit

b804fb7

DicomKit

1.0.0 SHA-256 96ada39062c07bca37511abfb6baac0a44d914fb705bac01d77cb02146fdac0e

DicomKit.Imaging

1.0.0 SHA-256 015b51ea833039d934ba153cae50d393fb77846430ca3fc3d65b4fb8cf4346ed

DicomKit.Web

1.0.0 SHA-256 2a2f4f7f02e1849929294062bee7dd8f3a24449428469c1fddb6982e77218a7b

DicomKit.Web.AspNetCore

1.0.0 SHA-256 daa1105881f1c0b60ca9c788d52d41445bd653a9d190c8862a2b2b1386d5e37c