Dicomweb Plugin QIDO-RS performance

Google Groups archive
1

Hello,

We’ve been using the orthanc-dicomweb plugin and noticing that the QIDO-RS retrieval at the Study Level becomes much slower as more studies (or studies with large instances, e.g. mammo tomographs) are added to Orthanc.

When I run Orthanc in verbose mode, I see that the plugin is making REST GET calls on /studies/{id}}/instances, which according to the documentation is used to “Retrieve all the instances of this patient in a single REST call”. This seems reasonable, since the plugin needs information about the studies.

What seems odd, though, is that the plugin is also making requests to /instances/{id}/file, which I suppose means that Orthanc is reading one file from each study in order to gather the metadata and return it for the QIDO-RS call. This appears to be done in the ExtractFields function in QidoRs.cpp (https://bitbucket.org/sjodogne/orthanc-dicomweb/src/cf5002bc63a885bf99c413718d612f199a8cd748/Plugin/QidoRs.cpp?at=default&fileviewer=file-view-default#QidoRs.cpp-331).

Assuming my understanding is correct, could this metadata be retrieved from the Orthanc database instead? E.g. From the documentation, would it be faster to parse the simplified-tags? (https://orthanc.chu.ulg.ac.be/book/users/rest.html#accessing-the-dicom-fields-of-an-instance-as-a-json-file).

Thanks,

Erik

2

Hello,

Please could you report an issue to our bug tracker?
https://bitbucket.org/sjodogne/orthanc/issues?status=new&status=open

Regards,
Sébastien-

3

Hello,

Any progress on that subject? I’m also trying to use Orthanc with the dicomweb plugin and the performance is really not good. I installed PostgreSQL in hope for better results, but it makes no difference. The good thing is I can use pgadmin’s dashboard to see some stats on the requests and it clearly shows a massive difference between equivalent QIDO and C-FIND requests. See the attached screenshots.

The QIDO search is only one request: http://127.0.0.1:8042/dicom-web/studies and it takes 10s to execute and return a list of 10 studies.
The C-FIND one is a STUDY request (the big spike) and then a SERIES request for each study (the little spikes) on the exact same database. The whole thing takes less than a second.

I have a “mainline” version of everything, the one that fixes the problem with STOW on large images.
W0629 10:02:17.530621 main.cpp:1241] Orthanc version: mainline (20170613T141013)

Orthanc is such a great PACS to work with (so easy to install and configure) i would love to keep it as my workhorse to test the implementation of QIDO/WADO/STOW in our viewer.

Cheers
JC

postgre CFIND.PNG

postgre QIDO.PNG

4

Dear Jean-Christophe,

I thank you for your interest in Orthanc.

This problem was introduced by Erik as issue #13 in our bugtracker:
https://bitbucket.org/sjodogne/orthanc/issues/13

The fix was included in version 0.3 of the DICOMweb plugin. The issue is now on-hold, as we received no further input about it since 2016-04-29.

Before digging further, please read the bugtracker, make sure that your version of the DICOMweb plugin is 0.3, and that both the Orthanc core and the DICOMweb plugin were compiled in Release mode, as explained in the FAQ:
http://book.orthanc-server.com/faq/troubleshooting.html#performance-issues

HTH,
Sébastien-

5

Hello Sébastien,

Thanks for the quick response. I installed the latest 1.2.0.2546 using the Osimis installer for 64 bits, for the same results.

It takes about 10s to retrieve the list of 10 studies with http://127.0.0.1:8042/dicom-web/studies.

It takes between 250ms to 2s to list the series of a study with http://127.0.0.1:8042/dicom-web/studies//series

It takes up to 10s also to list the instances of a series with http://127.0.0.1:8042/dicom-web/studies//series//instances

One thing I noticed also is that both study list and series list have stable request durations. I can do the same request multiple times in a row, it will take pretty much the same time to execute.
On the other hand, for the list of instances, the first call seems to trigger the reading of many files (images?). I can hear my hard drive getting very busy. Then on the next call for the same series, the request returns in less than a second, with no hard drive activity. If I list instance instances for another series, I will get the same pattern: first request very slow, second one fast.

Cheers
JC

6

Hello,

According to your last message, your problem is actually unrelated to original Erik’s issue. Indeed, you are talking about WADO-RS requests, whereas Erik was talking about QIDO-RS. The full reference of WADO-RS can be found at the following location:
http://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_6.5

According to this reference, the WADO-RS call corresponding to URI “/dicom-web/studies/{…}/series/{…}/instances” asks Orthanc to retrieve all the DICOM files of the given series, concatenate each of them, and return them as a single multipart answer.

Obviously, this means that Orthanc has to read all the DICOM files of the series from the disk, which explains why you hear a hard drive activity, especially if your series of interest is made of a large number of instances. The performance can be vastly impacted by other tasks running on your computer, notably if you use a low-performance HDD drive (a SSD would be much faster).

After your computer has read all the instances once, those instances might have been stored within some RAM cache, which explains why subsequent calls to the same URI can be much faster than the first call.

To summarize, the call to “/dicom-web/studies/{…}/series/{…}/instances” is expected to be time-consuming for large series, as it implies re-reading all of its instances from the hard drive.

I am much more surprised about the bad performance you report with “/dicom-web/studies” and “/dicom-web/studies/{…}/series”. These calls should imply reading a single DICOM file from each study or series, in order to retrieve the DICOM tags.

For instance, your “/dicom-web/studies” call should imply reading 10 DICOM files (one for each of the 10 studies you report having). I cannot understand why this operation could take 10s, except if you have very large DICOM files or if Orthanc stores its database remotely over a slow network.

Please could you provide a log produced in “–verbose” mode?
http://book.orthanc-server.com/faq/log.html

Sébastien-

7

Hello Sébastien,

Indeed, sorry for mixing the QIDO/WADO issues.

Here is the log in --verbose mode for the QIDO issue.

The database contains 10 studies (as shown in the attached snapshot).
The request starts at 18:16:41 and ends at 18:16:49

Thanks
JC

Orthanc.log (22.2 KB)

studiesforbug.PNG

8

Hello,

If I issue the following command over your log file:

$ grep -i ‘Reading attachment’ Orthanc.log | sort | wc -l
20

I observe that Orthanc only reads 20 files from the its database to fulfill the QIDO-RS request. All these files are JSON summaries, which means that no DICOM parsing is involved. Reading a number of JSON summaries that is twice the number of studies is the expected behavior: The QIDO-RS call first selects one instance for each study, then filters the tags of the selected instances from their JSON summary (which implies one file reading for each study), and finally creates an answer (which implies a second file reading for each filtered study).

As can be seen from this part of the log related to the filtering step, reading the JSON summaries is very fast (notice how the timestamp is the same):

I0629 18:16:41.069377 OrthancPlugins.cpp:1359] Plugin making REST POST call on URI /tools/find (built-in API)
I0629 18:16:41.069377 FilesystemStorage.cpp:154] Reading attachment “2584de72-e00f-4e87-87aa-f497b239a41b” of “JSON summary of DICOM” content type
I0629 18:16:41.069377 FilesystemStorage.cpp:154] Reading attachment “9cede5d9-8d10-42d3-83a6-9ba73e20ce0a” of “JSON summary of DICOM” content type
I0629 18:16:41.069377 FilesystemStorage.cpp:154] Reading attachment “3623ed3d-4188-4373-806e-8b8769ca72f0” of “JSON summary of DICOM” content type
I0629 18:16:41.069377 FilesystemStorage.cpp:154] Reading attachment “999f67e4-249a-41c1-a076-261a4dbc6676” of “JSON summary of DICOM” content type
I0629 18:16:41.069377 FilesystemStorage.cpp:154] Reading attachment “d9d5c99f-36ca-40c3-abe5-9ee813e4b8cd” of “JSON summary of DICOM” content type
I0629 18:16:41.069377 FilesystemStorage.cpp:154] Reading attachment “05f80f11-1f7d-43af-8647-af976d46fac6” of “JSON summary of DICOM” content type
I0629 18:16:41.069377 FilesystemStorage.cpp:154] Reading attachment “d6c12659-d7ae-41ec-bdf6-9d3d54b43672” of “JSON summary of DICOM” content type
I0629 18:16:41.069377 FilesystemStorage.cpp:154] Reading attachment “2c888924-1174-4ef3-9196-bb0c760b9837” of “JSON summary of DICOM” content type
I0629 18:16:41.069377 FilesystemStorage.cpp:154] Reading attachment “ef7704e1-781f-46d7-a222-ca6356a0e4d3” of “JSON summary of DICOM” content type

I0629 18:16:41.069377 FilesystemStorage.cpp:154] Reading attachment “651244bb-25e5-488c-98b3-ba1ab9aa74d9” of “JSON summary of DICOM” content type

So, your problem is not related to a bad performance of your filesystem. However, the calls to “/studies/{…}/instances”, that only make use of your PostgreSQL database, can take long time. For instance, 500ms are needed to access the list of instances of the study “5c0b88d2-c68f035f-b22a0a55-e8ebd753-c2d12245”:

I0629 18:16:46.715725 OrthancPlugins.cpp:1294] Plugin making REST GET call on URI /studies/5c0b88d2-c68f035f-b22a0a55-e8ebd753-c2d12245/instances (built-in API)
I0629 18:16:47.201405 OrthancPlugins.cpp:1294] Plugin making REST GET call on URI /instances/c86455a3-6244f520-1ac5972b-1c72b82f-a8bfb590/tags (built-in API)

The URI “/studies/{…}/instances” are notably used to populate the “Modality” and “Images” columns of your screenshot. As a consequence, I guess the bad performance you observe is not a bug within the DICOMweb plugin (even if some redundant calls to the REST API of Orthanc could probably be avoided), but instead a direct consequence of the following issue that is related to PostgreSQL:
https://bitbucket.org/sjodogne/orthanc/issues/47/index-improvements-for-pg-plugin

That’s for my analysis. In order to validate it, please could you try to reproduce exactly the same test, with the same database, but without enabling the PostgreSQL plugins? If the slowdown vanishes, your issue is a duplicate of issue #47.

Regards,
Sébastien-

9

Hello,

You are totally right. I removed PostgreSQL and did my little test. This time I get a response in less than 2s (see the attached log file). Much better.
Thanks a lot for the help.

I still have a few questions about the list of instances using http://127.0.0.1:8042/dicom-web/studies//series//instances
You mentionned in a previous response that it was a WADO-RS matter, but if I read http://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_6.7 correctly, it can also be interpreted as a QIDO-RS SearchForInstance request. Shall I open a new discussion thread for that?

Thanks again for the responsiveness.
Cheers
JC

Orthanc.log (22 KB)

10

Fine, thanks for the confirmation! Please stay tuned for improved versions of the PostgreSQL plugins.

Regarding your question about WADO-RS vs. QIDO-RS, you are absolutely right. All the requests you mentioned in your first post are indeed QIDO-RS… sorry for my mistake!

For future reference, I attach the very handy, official “DICOMweb Cheatsheet” to this message. In the “Description” column of the “Study Resources and Actions” box of this cheatsheet:

  • “Store” implies STOW-RS

  • “Query” implies QIDO-RS

  • “Retrieve” implies WADO-RS

Regards,
Sébastien-

dicomweb-cheatsheet.pdf (355 KB)