We are working with OHIF connected to Orthanc via the development server proxy. Performance is limited by chrome’s request blocking which limits 6 API requests per host. I know that we can fix this in production with HTTP/2. Any tricks for improving OHIF performance during development?
High performance loading is a huge topic with many variables. Here are some guidelines:
Using any kind of compression will likely make your loading CPU bound. Prefer to use uncompressed transfer syntaxes. You can apply gzip or deflate compression to reduce the size slightly (maybe 1.5:1 compression for CT).
Maximize network bandwidth and minimize network latency. The fastest way to do this is by enabling browser cacheing of the images so you don’t load them from the server each time. This may require adding some HTTP headers to your dicomweb server (or adding them via a HTTP proxy). Pulling images from a local dicomweb server is better than from a remote server.
Remove latency incurred from dicomweb servers. Most DICOMweb implementations are not optimized very well and often the bottleneck. Use a caching HTTP proxy to work around this or look into the dicomweb-static project to host in S3/CloudFront
Thanks @Chris for the great performance tips! Will save these for later. My real problem was that my Orthanc SQL-lite database had ballooned in size and the server was pegging the CPU with every request; hence why my network traffic looked like I was using a dial-up modem :-). Need to ask the right question to get the right answer, but can always learn something from a good answer to the wrong question.
FYI, following is OK performance / quality for ultrasound
1.2.840.10008.1.2.4.50 JPEG compression
nginx proxy
Orthanc > 1.10.0 - “Added a storage cache in RAM to avoid reading the same files multiple times from the storage. This greatly improves, among other things, the performance of WADO-RS retrieval of individual frames of multiframe instances”
