Increase simultaneous requests

[Alex979]

PR Checklist

• Brief description of changes
• Links to any relevant issues
• Required status checks are passing
• User cases if changes impact the user's experience
• @mention a maintainer to request a review

Hello, I am an intern at Google investigating ways in which to get optimal performance out of medical image viewers that integrate with the Google Healthcare API. One major optimization I've found is increasing the number of simultaneous requests made when fetching a series of DICOM instances/frames. So this PR adds a configuration to cornerstoneTools.stackPrefetch to increase the number of simultaneous http requests.

With the introduction of HTTP/2, there is no longer a limit of 6 simultaneous requests to a specific origin. Instead, one connection is made to a given origin and a hypothetically infinite number of requests can be made through that one connection (although browsers such as chrome do eventually limit these connections which appears to be around 100 requests). Increasing the number of simultaneous http requests higher than 6 yields major performance improvements as images load much faster.

Currently, a library used in Ohif react-cornerstone-viewport sets the cornerstoneTools maxSimultaneousRequests to 6, overriding any value that we set ourselves. However, I have opened a pull request to remove this configuration which would allow viewers to set these values to whatever they like. Thus, if that pull request gets merged, then we can set the maxSimultaneousRequests to whatever value we like, and I'll add a commit to update to the latest version of react-cornerstone-viewport.

I did some performance tests comparing the load times of different values of concurrent requests w/ Ohif, when loading a study with 619 instances in it, results below:

Max Simultaneous Requests	Time to Load all Instances
6	25.88s
10	17.21s
20	9.92s
50	9.59s
75	10.19s

It appears that after 20 max simultaneous requests, the added benefits become negligible. So in this PR I have set the maxSimultaneousRequests value to 20. As can be seen there is a very large decrease in load times for the 619 DICOM instances simply by increasing the number of simultaneous http requests, allowing users to view the instances much quicker and with less noticeable lag.

Relevant issues

#820

If anyone would like to test this change before the react-cornerstone-viewport PR gets merged, you can use my forked version of the library which won't override the maxSimultaneousRequests.

[dannyrb]

This all seems very reasonable. Thanks for laying out your case and for taking the time to draft a PR. I'll merge these changes and make sure they're duplicated in our beta branch.

[Alex979]

Thanks @dannyrb! One thing I wanted to change before marking this PR as ready for review was update the package.json in extensions/cornerstone to use the latest version of react-cornerstone-viewport once my PR in that library got merged, as this change currently won't be beneficial unless using the latest react-cornerstone-viewport. If you'd like, I could create another PR to update the package.json to use version 4.0.2?

[dannyrb]

👋 @Alex979, that would be great! The PR should:

• Bump the minimum version for react-cornerstone-viewport
• Include an updated yarn.lock

Thanks again ^_^

[swederik]

Thanks for the PR @Alex979 and the nice explanation. This is something that Egor (@pavertomato) also brought up when integrating OHIF with the Google Cloud Healthcare API. I have no problem removing the default and letting people set this themselves at the app level. The tricky thing is that when you have a large number of open requests, depending on the client's connection, the archive and server performance, the latency for each image can increase significantly.

Testing needs to take into account the behaviour of the user rather than just total time to load all instances. One thing that I know @pieper and @fedorov want to test for their work with the NCI Imaging Data Commons (which uses a proxy in front of the Google Cloud Healthcare API) is the perceived performance for a user loading a study and then quickly navigating to various locations in a stack, which is typically what we see end users doing. Currently, when the user navigates, we reset the stack prefetch queue to fetch around the image. I'm not sure how the perceived performance is impacted by changes to the maximum simultaneous open requests.