Compression only use one thread, even if configured number of Compression Threads > 1.

[CPaiva]

Hello,

Environment is:

Xeon Processor with 4 Cores / 8 Threads.

Linux Ubuntu Server 20.04.

dcm4chee-arc-psql:5.26.0-secure-ui on docker.

Archive attribute Compression Threads set to 4.

JPEG-LS Lossless Compression Rule, configured as following:

- Compression only use one thread, even if configured number of Compression Threads > 1.

Seems to be no difference in performance between set 1 thread vs multi threads. Also, with linux htop command, is possible to see that dcm4chee always use just one thread.

I Also try to set Compression Fetch Size to a bigger value than 100, but still no performance effects. (i dont really know what this attribute exactly does)

Seems to be related to this closed issue:

https://github.com/dcm4che/dcm4chee-arc-light/issues/1629

[CPaiva]

hello, it seems to be a bug, what is the correct way to report this to dcm4chee team ?

[CPaiva]

Hello, i find out that, if Scheduled Compression is enabled, the Multi thread compression with JPEG-LS LossLess Works fine ! (and ultra fast).

But if i leave the attribute Compression Delay Blank (Compress on Receive), dcm4chee do Not use Multi Thread compression.

For now Im using NO Compression Delay, because i want the study to be compressed as soon as possible, this way the physicians can Download the study already compressed via web.

- The system is supposed to use Multi Thread compression when No Compression Delay is set ? Or it is designed to use Multi Thread only when compression delay is set ?

In this page https://github.com/dcm4che/dcm4chee-arc-light/wiki/Compression-of-images I find this information:

Scheduled Compression may be used within the Compression Rule, "to avoid storage failures of objects to archive if compression of the images fail". (screenshot attached)

- So, Its not recommended use compression rule with NO Compression Delay set (Compress on Receive ?) For fail safe reasons ?

(Im talking about really big CT Studies, with average 3000 Instances and 500GB per study, 1000 Studies/Month)

What will be the correct approach for this scenario ? I would like to do the compression as soon as possible, but i want to ensure that will not be data lost if the compression fail, and i want to use Multi Thread Compression too.

- This way i think the better way to fullfill my needs, is to use delayed compression with a very low compression delay/compression pooling interval. Am i thinking the right way ?

- Just for better understanding, if i set Compression Delay attribute =  e.g.:  PT1S (1 second).

The entire study will be scheduled for compression 1 second after the whole study is received ? Or this attribute works at Series Level ? E.g.: Each serie is scheduled for compression 1 second after the whole serie is received ? Or at Instance level ? e.g.: Each Instance is scheduled for compression 1 second after is received ?

With my Setup/Load in mind, (Xeon 8Thread, 8Gb RAM - CT Studies, with average 3000 Instances and 500GB per study, 1000 Studies/Month ) Its safe to set the following low compression delay/compression pooling interval ? Or this could leave to concurrent compression/receiving jobs problems ?

Compression Delay attribute =  PT1S (1 second)

Compression Polling Interval= PT30S( 30 Seconds)

Compression Fetch Size= 100 (This 100 value is higher enough or very low ? How can i know if this number is the better value to my scenario?)

Compression Thread= 8

P.S. - Dcm4chee does some kind of verification process, to check if the result compressed image is identical after decompressed ? or some kind of checksum/file integrity check ?

Thanks !

[Amms]

Hello CPaiva,

Could you explain what is the purpose of Multi Thread Compression? What does it mean and its actual use case?