Orthanc slow in saving dicom files sent from a modality

If you look at your logs here, you’ll see that each file takes around 100ms to store on Orthanc.

I0528 17:01:00.787850          DICOM-5 main.cpp:353] Incoming Store request from AET MR450W on IP 10.200.200.70, calling AET SMARTPACS
I0528 17:01:00.816299          DICOM-5 FilesystemStorage.cpp:126] Creating attachment "1c466982-319c-4e39-90d1-0bf9d3dff6d5" of "DICOM" type
I0528 17:01:00.826973          DICOM-5 FilesystemStorage.cpp:156] Created attachment "1c466982-319c-4e39-90d1-0bf9d3dff6d5" (52.36KB in 10.65ms = 40.27Mbps)
I0528 17:01:00.827789          DICOM-5 FilesystemStorage.cpp:126] Creating attachment "c8b0f63a-eea4-4076-bb5b-0892461b62b4" of "DICOM until pixel data" type
I0528 17:01:00.875178          DICOM-5 FilesystemStorage.cpp:156] Created attachment "c8b0f63a-eea4-4076-bb5b-0892461b62b4" (5.53KB in 47.35ms = 956.22kbps)
I0528 17:01:00.888712          DICOM-5 ServerContext.cpp:762] New instance stored (a47167fb-41c50411-e509add8-49ab05b4-1c0d40cd)

Once you send the same study again, orthanc is replacing the files and, for this, it needs to delete the old files and you’ll observe that deletings are super slow on your system - I don’t know why.

I0528 18:03:51.957464         DICOM-13 main.cpp:353] Incoming Store request from AET MR450W on IP 10.200.200.70, calling AET SMARTPACS
I0528 18:03:51.978827         DICOM-13 FilesystemStorage.cpp:126] Creating attachment "f383e393-951d-474e-8867-fa95449a61f0" of "DICOM" type
I0528 18:03:51.998270         DICOM-13 FilesystemStorage.cpp:156] Created attachment "f383e393-951d-474e-8867-fa95449a61f0" (62.68KB in 19.41ms = 26.46Mbps)
I0528 18:03:51.999588         DICOM-13 FilesystemStorage.cpp:126] Creating attachment "39839d65-26ce-404e-a3a2-66faeaaad119" of "DICOM until pixel data" type
I0528 18:03:52.046099         DICOM-13 FilesystemStorage.cpp:156] Created attachment "39839d65-26ce-404e-a3a2-66faeaaad119" (5.63KB in 46.48ms = 992.00kbps)
I0528 18:03:52.048530         DICOM-13 FilesystemStorage.cpp:266] Deleting attachment "f383e393-951d-474e-8867-fa95449a61f0" of type 1
I0528 18:03:52.499831         DICOM-13 FilesystemStorage.cpp:266] Deleting attachment "39839d65-26ce-404e-a3a2-66faeaaad119" of type 3
I0528 18:03:53.053312         DICOM-13 ServerContext.cpp:766] Instance already stored (d65f9b16-d6f647aa-209cfe8e-29e16f19-7c435cca)

You may try to enable the delayed-deletion plugin and check if that helps (if the storage is slow, that will help, if the DB is slow, that won’t be at least we’ll know who is the culprit).

HTH,

Alain