C-Find performance

[jef...@gmail.com]

Hi,

First thanks for creating a PACS that is so easy to get running. I have setup what may be a fairly large instance of Orthanc- here are the stats:

{
"CountInstances" : 920510,
"CountPatients" : 1777,
"CountSeries" : 22914,
"CountStudies" : 2368,
"TotalDiskSize" : "397710981171",
"TotalDiskSizeMB" : 379286,
"TotalUncompressedSize" : "397710981171",
"TotalUncompressedSizeMB" : 379286
}

I am trying to issue a C-Find request to find all the SeriesInstanceUIDs in a given study- it looks something like this:

dcm4che-3.3.7/bin/findscu -c ORT...@mypacs.edu:4242 -m StudyInstanceUID=1.2.323.3680043.4.1008.1.1.1.1 -L SERIES -M StudyRoot -i SeriesDescription

It takes a very long time (in the minutes), although seems to speed up on subsequent requests. I am using the postgres plugin with images stored in the database. When I log the postgres queries (see bottom), it looks like it might be trying to read a number of DICOM files from the DB

Does Orthanc have to read the DICOM files themselves out of the DB to answer this query? If so, would it be better to use the disk storage rather than in the db?

Thanks,
Jeff

LOG: statement: BEGIN
LOG: execute 1a0e32a7-777f-4993-9fa1-cda8e4d326c4: SELECT content FROM StorageArea WHERE uuid=$1 AND type=$2
DETAIL: parameters: $1 = 'ff0e65a6-6bfc-48bd-9672-dea25ea77d61', $2 = '2'
LOG: fastpath function call: "lo_open" (OID 952)
LOG: fastpath function call: "lo_lseek" (OID 956)
LOG: fastpath function call: "lo_tell" (OID 958)
LOG: fastpath function call: "lo_lseek" (OID 956)
LOG: fastpath function call: "loread" (OID 954)
LOG: fastpath function call: "lo_close" (OID 953)
LOG: statement: COMMIT
LOG: execute da8e8964-89c7-47fa-8bf5-6cf92046b426: SELECT internalId, resourceType FROM Resources WHERE publicId=$1
DETAIL: parameters: $1 = '5ad6070c-c670c133-056b18d3-911b9836-953ffc3c'
LOG: execute 004244f2-9a10-489c-9cee-dc16fb5c0ada: SELECT uuid, uncompressedSize, compressionType, compressedSize, uncompressedHash, compressedHash FROM AttachedFiles WHERE id=$1 AND fileType=$2
DETAIL: parameters: $1 = '187915', $2 = '2'
LOG: statement: BEGIN
LOG: execute 1a0e32a7-777f-4993-9fa1-cda8e4d326c4: SELECT content FROM StorageArea WHERE uuid=$1 AND type=$2
DETAIL: parameters: $1 = '86f1c2ec-9e01-498c-aa30-9a79f60c587a', $2 = '2'
LOG: fastpath function call: "lo_open" (OID 952)
LOG: fastpath function call: "lo_lseek" (OID 956)
LOG: fastpath function call: "lo_tell" (OID 958)
LOG: fastpath function call: "lo_lseek" (OID 956)
LOG: fastpath function call: "loread" (OID 954)
LOG: fastpath function call: "lo_close" (OID 953)

[Sébastien Jodogne]

Dear Jeffrey,

I thank you much for reporting this performance issue.

I confirm this is a bug within the core of Orthanc. I have just applied a patch to the mainline code, and a Docker build has just been triggered:

https://bitbucket.org/sjodogne/orthanc/commits/b9428d5f7eafe409c36302e4255753f5a4fe2dfc

Would it be possible for you to confirm this patch actually solves your problem?

Regards,

Sébastien-

[Sébastien Jodogne]

BTW, also make sure to compile Orthanc in Release mode:

https://orthanc.chu.ulg.ac.be/book/faq/troubleshooting.html#performance-issues

[Jeffrey Miller]

Thanks Sébastien, I pulled the latest orthanc-plugins docker image (docker.io/jodogne/orthanc-plugins         1.1.0               ed26dec33c16) but I am still seeing the delayed C-Find response. Was the fix included in that image?

[Sébastien Jodogne]

Thanks Sébastien, I pulled the latest orthanc-plugins docker image (docker.io/jodogne/orthanc-plugins         1.1.0               ed26dec33c16) but I am still seeing the delayed C-Find response. Was the fix included in that image?

The patch is introduced in the mainline version of Orthanc, not in the 1.1.0 release.

Here is a sample Docker session (you simply have to use "jodogne/orthanc-plugins" instead of "jodogne/orthanc-plugins:1.1.0"):

# sudo docker pull jodogne/orthanc-plugins

# sudo docker run --rm --entrypoint=cat jodogne/orthanc-plugins /etc/orthanc/orthanc.json > /tmp/orthanc.json

=> Add the following definition to the "DicomModalities" section of "/tmp/orthanc.json", and adapt your PostgreSQL parameters:

  "DicomModalities" : {

    "sample" : [ "FINDSCU", "127.0.0.1", 2000 ]

  }

=> Then, actually start Orthanc:

# sudo docker run -p 4242:4242 -p 8042:8042 --rm -v /tmp/orthanc.json:/etc/orthanc/orthanc.json:ro jodogne/orthanc-plugins /etc/orthanc --verbose

HTH,

Sébastien-

[Jeffrey Miller]

Thanks! That worked. The response is quick now. Ultimately I ended up using the the dicom_tools/lookup API to translate from DICOM UID to Orthanc ID, and then I just used the Orthanc REST API to get the information I needed. This actually allowed me to remove a dependency on GDCM in my code. Thanks again for a great project.

[Sébastien Jodogne]

Fine, thanks for the positive feedback!

Sébastien-