Too many hits on DB, and Slow performance caused by DB Locks

General
1

I was playing around with some PACS solutions and got interested in Orthanc.
I am now testing Orthanc on Docker with ODBC (MSSQL Server) & Indexer plugin on a decent PC (i7-12700k, 64GB DDR5, 4TB Gen4 NVMe, RTX 3080).

The dicom viewer client requests /studies/%studyId/instances to get all instances of the selected study to build its structure.

For example, this CBCT image from jaw has 1 study, 2 series with 1306 instances, each series has 653 images with a total size of ~1GB

It executed ~8000 queries against the Database and took ~8 seconds.
Considering this is running on a Perfect LAB environment each roundtrip of query took ~1ms
So if we add network delay in best case 5ms and worst case 30ms we have 40~240 seconds delay. (its common infrastructure design that APP&USERS related servers, DATA&Database servers, and BACKUP servers are separated physically and logically restricted by access)

Also in most RDBMS when we run a query that joins two or more tables we will face Table/Page/Record locks.
So you can imagine if the Indexer or Houskeeper plugin jumps into play with 10 users it’s gonna be a total disaster.

I’m new to Orthanc so definitely, there is a lack of knowledge on my part, Are there any tips and tuning for this any help is much appreciated.

Untitled
Untitled4092×2090 463 KB

2

Hi Patachi,

This is a known issue and our plans is to replace these 8000 small queries by ~5-6 large queries. I have planned to work on that in the near future but this will take some time.

Best regards,

Alain

1 Like
3

That’s great, Thanks for this great job.

I don’t know much about the DICOM file structure and PACS Server required standards.

But as I am playing with some PACS solutions and Dicom Viewer Apps I noticed that only a few of Dicom metadata are used by PACS Servers just for finding Studies(e.g. date & modality) and searching patients by (e.g. patient-id & name) all other metadata are only used by Dicom Viewer Apps, So it would be great if we just store some useful tags separately (in a manner that it could be indexed by DB) and store studies and all of its images metadata in one big JSON chunk because most of Dicom Viewer App need all of them together when they try to open a study.

This will improve the Inserting/Indexing of Dicom files (preventing DB locks) and speed up searching and retrieving Studies with just a single query.
Storage is cheap, and Dicom files very rarely get edited, so having duplicated data for better performance is way more preferable.

4

That is basically how Orthanc works.