Dicom zip creation performance

Google Groups archive
1

Hi there,

At my workplace, we have some Orthanc instances in production. Some costumers have reported that the async zip creation process via jobs is slow (~ 5 mins ). There are some method to increase the performance of this process? Maybe some faster compression algorithm with bigger zip size?

Best regards.

2

Hello,

The time needed to create a ZIP file evidently depends on the size of the study, on the bandwidth of the storage area where the DICOM files are stored, and on the network bandwidth of the client that downloads the ZIP file. CPU is not a big deal here.

First consider tuning your infrastructure for best performance:
https://book.orthanc-server.com/faq/scalability.html#recommended-setup-for-best-performance

There is currently no option to change the compression level, but I highly doubt this would bring a noticeable improvement.

As you are working for a commercial company, get in touch with professional assistance if you need further investigation:
https://book.orthanc-server.com/users/support.html#finding-professional-assistance

Regards,
Sébastien-

3

Hi Rodrigo,

If you’re using an object-storage plugin (S3, Azure, Google), you might have the same issue as Salim and Julien: https://groups.google.com/g/orthanc-users/c/E8LNXEPMty0/m/d7XvwS4JAgAJ?utm_medium=email&utm_source=footer&pli=1

Their patch is not yet included in Orthanc but I’ll look at it soon.

Best regards,

Alain.

4

Hi,

For performance issue you have to check on database latency and enventually object storage latency.

If you are using a cloud provider pay attention to the level of service you choose.

Here are some informations about Azure

  • The performance of the database is highly different depending on the database size, the “basic” offer is very low performance, the “general puprpose” is OK but need at least 4 CPU (if only 2 the performance drop), maybe “memory opimized” level could give better performance (yet to be evaluated)
  • Better to connect orthanc using local ip adress of the database by putting a terminaison endpoint of the database into the azure vnet

It this scenario we achieved 7ms for a query response on the database.

On the object storage size, the prenium level is faster but 10 time more expensive than the “hot” storage.
Hot storage is OK, we achvied near 6Mo/sec when donwloading the zip stream.

I think when Alain will include the mutithreding of fetching images in the ZIP generation we should increse a this speed as the multithreading will multithread both db access and object storage access and so reduce the latency impact.
However I don’t expect a huge gain maybe 20-30% which is already fair.

Take account that DICOM collection is slow in EVERY dicom PACS, this is due to data splitted into multiple instance that put a high pressure in I/O data access.
If you are not in the cloud use a SSD Nvme will give better performance (in particular for the database).

However if you fine tune your database performance and storage access you can achieve a zip streaming of at least 6 Mo/sec with an immediat download start which is incredibly high for a DICOM storage system.

Best regards,

Salim