Improving Orthanc Explorer search speed on a large Database

General
1

Hi All,

I’m running into some performance issues with Orthanc Explorer 2 and would really appreciate any insights. I’m still relatively new to Orthanc so please excuse any technical inaccuracies!

I work for an MRI research institution, and we manage fairly large datasets — roughly 75,000 studies and ~100 million instances. Searches in OE2 are taking 30 to 90+ seconds, which is challenging for our users. Although, interestingly if we use the legacy Orthanc Explorer, searchers return results almost instantly for the same database.

Our Setup

  • Orthanc in Docker on a Windows Server

  • PostgreSQL backend on SSD; image data on HDD

  • OE2 config includes:

    • STUDY_LIST_SEARCH_MODE: “search-button”
    • STUDY_LIST_CONTENT_IF_NO_SEARCH: “empty”

We’re using Docker image 25.2.0, so I don’t think this is related to the PDF report issue I’ve read about in other posts.

I completely understand there are limits when working with large databases, but I’d appreciate any thoughts as to whether there are any OE2-specific or general Orthanc optimisations that could help improve search responsiveness.

Thanks in advance for your time and help!

Best,
Jacob

2

Hi Jacob,
I had the same situation which was being reported here : /tools/find MetadataQuery - #9 by Christophe . In fact, Orthanc does not handle well search on date rage.

3

Hi,

What kind of searches are you performing ?

There is a difference between the legacy OE and OE2 when you search by PatientName or PatientID: OE2 automatically adds wildcards so if you search for SMITH in the PatientName field, OE wil search for SMITH while OE2 will search for *SMITH*. Therefore, the exact match search might be a lot faster.

To perform exact match searches in OE2, you can either search for "SMITH" or set this configuration:

"AutoAddWildcardsToSearchFields": true,     // Automatically adds wildcards to textual search fields in the local and remote study tables.
                                            // When this is set to true (default), searching for 123 in the UI actually searches
                                            // for *123* in DICOM and Rest API.  Searching for "123" in the UI actually removes the
                                            // wildcard and performs an exact-match.
                                            // When this is set to false, the value used in the DICOM and Rest API filters exactly matches
                                            // the input in the UI.  Adding double-quotes is meaningless in this configuration and will
                                            // very likely lead to no results.
                                            // New in v 1.7.2

Hope this helps,

Alain

2 Likes
4

Thanks, Christophe and Alain — both very helpful pieces of information!

@alainmazy I wasn’t aware that the legacy OE doesn’t automatically add wildcards, so my previous searches would have been without. I’ll try setting the wildcard variable to false and see if there’s a noticeable improvement. I’ve already tested this in my dev environment, and it’s working well so far. If there is a significant improvement on the live system too, then I’d say the requirement to manually add wildcards if/when needed seems like a reasonable trade-off!

Are you aware of any differences in backend resource usage between OE and OE2? I’m wondering if performance differences might also be factored by system load, and whether hardware upgrades could help.

Cheers,
Jacob

5

Just a quick update to confirm that search speed has markedly improved after disabling auto-wildcards in orthanc.json under "UIOptions":

json

“OrthancExplorer2”: {
“IsDefaultOrthancUI”: true,
“UiOptions”: {
“EnableApiViewMenu”: false,
“EnableShares”: false,
“AutoAddWildcardsToSearchFields”: false,
“ViewersIcons”: {
“stone-webviewer”: “bi bi-eye-fill”
}
}
}

This does require exact searches by default; however, the trade-off in response time is worth it. Manually adding wildcards to a search is still fairly slow, but we can now offer a viable workaround.

Thanks for your help!
Jacob