Slow Queries

Google Groups archive
1

Hi guys! me again.

this is our environment:
OS: Ubuntu 20.04
Dicom Server: Orthanc 1.11
DB: PostgreSQL 13.3
Plugins: S3-storage , PostgreSQL 4.0, Dicom-web 1.8

we are doing a query of the studies of the last 30 days, we use osirix, and the response is too slow. We also tried to do the curl directly http://172.22.20.150:8042/dicom-web/studies?StudyDate=20220507-20220607

this is the result and the query took 44 seconds

I0609 12:33:39.741879 HttpServer.cpp:1244] (http) GET /dicom-web/studies
I0609 12:33:39.742593 OrthancPlugins.cpp:2368] (plugins) Delegating HTTP request to plugin for URI: /dicom-web/studies
I0609 12:33:39.744376 PluginsManager.cpp:161] (plugins) Arguments of QIDO-RS request: [StudyDate=20220507-20220607]
I0609 12:33:39.745078 PluginsManager.cpp:161] (plugins) Body of the call from QIDO-RS to /tools/find: {
“Expand” : true,
“Full” : true,
“Level” : “Study”,
“Limit” : 0,
“Query” :
{
“0008,0020” : “20220507-20220607”
},
“RequestedTags” :
[
“0008,0020”,
“0008,0030”,
“0008,0050”,
“0008,0056”,
“0008,0061”,
“0008,0090”,
“0008,0201”,
“0010,0010”,
“0010,0020”,
“0010,0030”,
“0010,0040”,
“0020,000d”,
“0020,0010”,
“0020,1206”,
“0020,1208”
],
“Since” : 0
}

I0609 12:33:39.745205 OrthancPlugins.cpp:3190] (plugins) Plugin making REST POST call on URI /tools/find (built-in API)
I0609 12:33:40.340088 ServerContext.cpp:1416] Number of candidate resources after fast DB filtering on main DICOM tags: 478
I0609 12:33:41.198694 ServerContext.cpp:1566] Number of matching resources: 478

we saw this:

“Latency For some queries to the database, Orthanc performs several small SQL requests. For instance, a request to a route like /studies/{id} can trigger 6 SQL queries. Given these round-trips between Orthanc and the DB server, it’s important for the network latency to be as small as possible. For instance, if your latency is 20ms, a single request to /studies/{id} might take 120ms. Typically, a latency of 1-4 ms is expected to have correct performances.”

Our database and Orthanc are on the same server.

Could it be that these 6 triggered queries are causing the delay?
I attach our Configuration.json

Is there anything we can do to improve the speed?

Thanks!

Regards.-

Configuration.json (16.5 KB)

2

Hi,

Your configuration seems correct. I’m observing similar performances here on a large DB when the DB is “cold”.

2 ways to speed it up:

  • In OE2, I’m limiting the number of results to 100 and ask the user to refine his search criteria if reaching 100 results → in my case, this limits time to 7 seconds
  • Requesting “ModalitiesInStudy” and “NumberOfStudyRelatedSeries” is time consuming too since it has to make more requests at series level, you might want to request it a bit later or only if required. I had some plans to cache them in DB as well but that’s quite tricky since they change along the study life so I’ve not done it yet.

Best regards,

Alain.

3

Good morning. Thanks for the reply.

What do you mean by “cold db”? We see the same times doing the same query more that once.

If we limit results, which results do you get on the response? Random ones? or alphabetically?

Thanks

4

By cold, I meant that I have observed queries that took 7-8 seconds the first time and 700ms the second time. That was on a 300GB postgres DB and I assume that part of the data was not in the PG server RAM the first time hence the difference.

If you limit the results, you get “random” results indeed.

Alain.