Performance of OHIF Viewer with Orthanc/Postgres

Hello,

I’m again looking at OHIF/Orthanc performance. (I brought this up back in March here, but thought I should start a new thread to address it properly.)

I have OHIF, Orthanc (with Osimis viewer plugin) and Postgres installed on a Google VM (n1-standard-2: 2 vCPUs, 7.5 GB memory). Postgres only holds the index (on an SSD). I’m running Orthanc 1.3.2.

I compared OHIF/Orthanc against the Osimis viewer plugin to Orthanc; measured on both a database (‘Minimal DB’) holding a single study of 1742 instances (~1GB), and a DB (‘Maximal DB’) holding many studies totaling 1.7 million images (700GB). I ran timings on three basic operations.

  1. Presenting a list of all the available data. Osiris presents a list of all patients. OHIF presents a list of all studies for all patients.
  • Osimis does this ~instantly on the minimal DB, and takes about 15 seconds on the maximal DB

  • OHIF does this quickly against the minimal DB, but takes forever against the maximal DB. I gave up after 25 minutes.

  1. Loading a study. For both OHIF and Osimis viewer, this is the step which opens the viewer and displays a thumbnail for each series in the study. I tested using a single study of 10 series, 1742 instances, ~1GB.
  • Osimis and OHIF seem pretty comparable, taking around 6-9 seconds for this operation against the minimal DB.
  • Against the maximal DB, Osimis continues to take about 6-9 seconds, but OHIF load time increases to 65 seconds.1. Loading a series. For both OHIF and Osimis, this is the step in which the individual images comprising the series are uploaded to the viewer. I tested this against a series of 300 instances, 512x512 resolution.
  • Surprisingly OHIF loads the series faster than Osimis. OHIF is loading at a rate of about 15+ instances/second, and Osimis at about 5 instance/second. Approximately 25% of the Osimis load time is for loading the low resolution images. In my configuration, I am running the viewers on my local Mac, so the rate is actually a function of network BW to the VM, but the relative rate between OHIF and Osimis is still significant.
    There is some discussion of OHIF/Orthanc performance on this thread on the Cornerstone Platform Google Group, and which suggests that the OHIF slowdown, as additional data is loaded to the DB, might be due to the number of Orthanc/Postgres queries. Do you have any thoughts on this?

I’m also interested in your thoughts on OHIF vs. Osimis series load performance (3. above).

Thanks as always,
Bill

Hi Brian,

Thanks for this analysis. Unfortunately, this requires quite a deep investigation which we don’t really have time to perform right now.
However, note that we have planned to work on DB optimizations in August/September and we’ll for sure come back to your analysis at that time.

Best regards,

Alain

Hello,

To expand a bit on Alain’s answer, we are currently aware of 2 main sources of inefficiencies related to databases in Orthanc:

  1. Optimizations can be done when handling “find” requests returning many results, notably as a consequence of “range” queries (e.g. “search studies from the last week”). Here are our action points:
  • “Range” queries could be optimized as early as Orthanc 1.4.0 for SQLite [1]. A new release of the PostgreSQL plugin will be scheduled a bit after.
  • The configuration options “LimitFindResults” and “LimitFindInstances” can already mitigate the effect of “universal” requests returning a huge number of results.
  • As said by Alain, other optimizations will be investigated in August/September.1. The PostgreSQL plugin does not take into account the network latency. This can be a huge source of inefficiency in “cloud” scenarios such as yours, if Orthanc does not run on the same computer as the PostgreSQL database [2]. Reordering and grouping some SQL requests might improve the performance (this will be investigated in August/September), but you are always invited to make Orthanc and PostgreSQL run on the same host if you want best performance.
    In either case, financial support from the industry would be welcome to help us tackling the second point, as it is clearly specific to “enterprise/cloud” scenarios, and has very limited impact on the average Orthanc user.

HTH,

Sébastien-

[1] https://bitbucket.org/sjodogne/orthanc/issues/41/additional-range-identifierconstrainttype
[2] https://blog.2ndquadrant.com/postgresql-latency-pipelining-batching/

Thanks for your reply Sébastien. To clarify, the OHIF server, Orthanc and PG are all running on a single VM, so I don’t think network latency should be a problem in this configuration.

Looking forward to your optimizations.

Bill

Please also check out the following message:
https://groups.google.com/d/msg/orthanc-users/wWmD6_LG9wg/gapRmBLLBgAJ

Dear Bill,

You should give a new try by combining the just-released PostgreSQL plugin 3.0 together with Orthanc 1.5.2:
https://www.orthanc-server.com/download.php

The combination of these two releases is notably focused on improving the performance of Orthanc together with PostgreSQL.

HTH,
Sébastien-

Does the PostgreSQL plugin 3.0 also improve performance for setups running Orthanc and PostgreSQL on the same machine?

Yes, it should improve C-FIND queries over large databases.

Hello,

Any update on this?
I am facing the same issue using OHIF viewer.
I tried fine tuning setting for OHIF viewer as specified here https://book.orthanc-server.com/plugins/dicomweb.html but no way to make it work…

Timeout when OHIF request metadatas over DICOM WEB plugin…
Also tried:

“StorageAccessOnFind” : “Never”,
“HttpTimeout” : 180,

but nothing change, timeout after one minute.

Thanks :slight_smile:

Pe joi, 24 ianuarie 2019, la 16:31:14 UTC+2, s.jo...@gmail.com a scris:

Hello,

From what I know, the performance issues regarding the Orthanc/OHIF combination are now solved:
https://github.com/OHIF/Viewers/issues/1536

https://groups.google.com/forum/#!topic/orthanc-users/y1N5zOFVk0M

The fact of using the PostgreSQL plugin instead of built-in SQLite in order should have only marginal impact on performance.

Please make sure to read our FAQ about scalability:
https://book.orthanc-server.com/faq/scalability.html

In either case, you should follow the installation guide provided by OHIF, and ask to the OHIF community:
https://docs.ohif.org/configuring/data-source.html

Sébastien-

Stumbled upon this old post. Thought I would add a few comments and see what has evolved over the last couple of years. I’ve been building a front end for Orthanc integrated with a primitive RIS. I spent quite a bit of time playing around with a good way to display things because the results sets could be thousands, hundreds or just a few since we have a portal for admins, readers, doctors and patients. The initial approach was to just allow for display time ranges for studies, along with various search params on the dicom tags, along with allowing for a selection of the number of studies to display on the page (i.e. a limit). Recently, Sébastien clued me in on how to write Python scripts, so I’m working with an example that he put on the WIKI to sort of facilitate pagination in search results. That is kind of off-topic,
but a nice feature.

I do have both viewers integrated into the app, and that is user selectable. I’ll make it a little simpler after pagination is added.

I added screen shots for the patient exam list and the exam list format for readers. They are pretty much the same, except for some additional features for readers and access

to the whole database for readers. The search tools work pretty well.

I am curious if you arrived at any conclusions since the post. We’re using the viewers basically so patients and referring doctors can see their studies. The readers don’t
use Osimis or OHIF for reading since another workstation is used for that, but the App does have some HL7 support for ORU and ORM and ADT messages, and there
are templated reports that generate HTML and PDF reports. That works fairly well now also. Osimis viewer actually supports the display of PDF reports generated through
the REST API. OHIF does not display those as I have it configured now.

My partner plans to use E-Film or Osirix for actual reading. I keep looking around for other viewers for a number of reasons.

One applications would be to bundle a cross-platform viewer with downloaded .zip and .dcm studies so that the user could also view downloaded studies offline. Haven’t really
looked into that much, but probably not too hard to add.

I think Osirix is the only OS X viewer that is FDA approved, and there are a handful of viewers for Windows. I am partial to Mac OS, but I actually think Osirix is probably
the best unless you buy a commercial PACS system.

https://nroduit.github.io/en/. looks like it could be useful also.

Regarding viewers, clicking on the little magnifying glass slides out the study in the viewers.

The Osimis viewer does indeed load the thumbnails and initial display at least twice as fast as OHIF, and the performance otherwise is similar, although I still think Osimis is faster. My setup really just displays the viewer on demand for a single study, which is

pretty much how the Osimis viewer works, but for OHIF, I generate a URL on the fly and then just display that study using OHIF without displaying the study list, because I don’t

need and don’t want the study list that they provide. I’m just using the viewer feature of OHIF. I do kind of like it that OHIF is still developed, supported and somewhat customizable,
and it uses dicomweb.

I think the Osimis viewer has a max 2 x 2 matrix, whereas OHIF can be 3 x 3. You really kind of need a large monitor to use the 3 x 3 layout since the annotations obscure the images on
OHIF and the images are just small if you use a 3 x 3 layout with something other than a large monitor.

I haven’t analyzed this, but I think the image quality is also just better with the Osimis Viewer than with OHIF (the dynamic range, contrast, etc. just seem better subjectively).

Also, wondering if you’ve had experience using Postgres vs. MySQL and the file system vs. database and SSD vs. HDD.

We’re just starting up and picking hardware, etc. Postgres is apparently better supported and more robust than the MySQL plug-in, although I would prefer to use MySQL.

Also, you can apparently store the images on the file system or in the DB, which is surprising to me.

A reasonable setup sounds like using an SSD for the System Disk and Apps and for the datbase, nad then just use a HDD filesystem for the images and backups.

patientlist.pdf (93.3 KB)

readerlist.pdf (131 KB)

Hi Stephen,

I really advise you to use SSD for database in order to keep performances…
HTH,