This page shows best practices for improving performance when working with DICOM data in the Cloud Healthcare API.
Maximizing frames per second (FPS) in an imaging viewer
The healthcare-imaging-performance-test tool provides benchmarks that let you preview what FPS you can expect for a DICOM medical imaging viewer that pulls data from the Cloud Healthcare API.
Sending requests concurrently
For the best FPS performance, send requests concurrently. For example, under the following conditions you can improve FPS from 30 FPS to 60 FPS when going from six concurrent requests to 20:
- Using no compression
- When the DICOM data is all in the same region
- When the DICOM images are 0.5 MB in size
Retrieving frames in a single request
methods efficiently return multiple DICOM files in a single request.
Using these methods, you can retrieve images at the same rate as using an
optimal number of concurrent requests. You can call these methods in a single
request instead of using concurrent requests if the following are true:
- The client can store the entire study in memory, or the client can parse the response as a stream to handle one DICOM instance at a time
- You don't need to customize the order of the retrieved images
Improving performance for web viewers
The following sections apply to retrieving DICOM images when using a web viewer.
Increasing maximum concurrent requests
When using a web-based viewer, most browsers enforce a maximum number of connections per host. This number is typically six. However, in practice there is no restriction on the maximum number of concurrent requests because:
- Most browsers use HTTP/2 by default if the server supports HTTP/2
- HTTP/2 uses a single connection for all requests
For example, if you use Cornerstone.js
to build a viewer, you can modify the maximum number of concurrent requests
to a number that is optimal for your viewer by changing
when configuring Cornerstone.js.
Using web workers
For example, if you modify your HTTP request processing to web workers, you can effectively double your viewer's FPS from 30 FPS to 60 FPS assuming a 30 millisecond request processing overhead.