I’m currently trying to debug a very slow performance we are seeing in the Stone Web Viewer when viewing Siemens Multi Frame MR images. The problem is that it takes seconds to scroll from one slice to the other and additionally the initial loading is quite slow (but still okay).
According to the browsers network tab a lot of time is spend waiting for a response from the dicom-web plugin to retrieve the instance
and indeed when I curl the same request I essentially get the same result with an orthanc process running at 100% for the whole time:
$ curl -k "https://xxx/dicom-web/studies/1.2.276.0.38.1.1.1.5631.20230426155840.46101039/series/1.3.12.2.1107.5.2.43.166260.2023042616125429766190680.0.0.0/instances/1.3.12.2.1107.5.2.43.166260.2023042616125450438890727" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0" -H "Accept: multipart/related; type=""application/dicom""; transfer-syntax=*" -H "Accept-Language: de,en-US;q=0.7,en;q=0.3" -H "Referer: https://xxx/stone-webviewer/index.html" -H "Authorization: Basic xxx" -H "Connection: keep-alive" --output test.dcm --compressed
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 34.7M 100 34.7M 0 0 4167k 0 0:00:08 0:00:08 --:--:-- 10.6M
When I remove the --compressed parameter the data is transferred much faster:
$ curl -k "https://xxx/dicom-web/studies/1.2.276.0.38.1.1.1.5631.20230426155840.46101039/series/1.3.12.2.1107.5.2.43.166260.2023042616125429766190680.0.0.0/instances/1.3.12.2.1107.5.2.43.166260.2023042616125450438890727" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0" -H "Accept: multipart/related; type=""application/dicom""; transfer-syntax=*" -H "Accept-Language: de,en-US;q=0.7,en;q=0.3" -H "Referer: https://xxx/stone-webviewer/index.html" -H "Authorization: Basic xxx" -H "Connection: keep-alive" --output test.dcm
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 76.1M 100 76.1M 0 0 60.8M 0 0:00:01 0:00:01 --:--:-- 60.8M
Looks like a lot of time is spend on the compression of the data on the server since the multi frame MR series are quite big (and I might suspect that this might be also related to the slow scrolling performance in case the stone viewer always uncompresses the data for each slice?) so the question is if there is an option/configuration to disable compressed transfer for the stone web viewer or worst case for the dicom-web plugin entirely?
I started experimenting with this and going through the source code,
basically trying to comment out all SetHttpHeader("Accept-Encoding", "gzip"); calls I could find in the stone web viewer plugin code (without success). While doing so I stumbled across and older comment from 2019
// TODO: review the following comment.
// - Commented out by bgo on 2019-07-19 | reason: Alain has seen cases
// where gzipping the uint16 image took 11 sec to produce 5mb.
// The unzipped request was much much faster.
// - Re-enabled on 2019-07-30. Reason: in Web Assembly, the browser
// does not use the Accept-Encoding header and always requests
// compression. Furthermore, NOT
which sounds like it could be related. Unfortunately it states that in Web Assembly the browser always requests compression. I’m not a web developer, so I have no idea how to dig deeper here, any feedback or ideas would be highly appreciated on how to turn off the compression.
I’m afraid that the situation has not changed since 2019 and the StoneViewer Web Assembly code is still not able to disable gzip compression when issuing the request to Orthanc.
Could you possibly share an anonymized file ? I don’t think I have a multiframe MR here. Note sure I can help directly but at least I can do some analysis …
As a work around or alternative, would it be possible to configure/change the dicom-web plugin so that it does not accept compression requests and ignores them, basically returning non compressed data (which the Web Assembly should be able to handle as long as the header is set correctly?)
BTW, have you already tried playing with this Orthanc core configuration ?
// Enable HTTP compression to improve network bandwidth utilization,
// at the expense of more computations on the server. Orthanc
// supports the "gzip" and "deflate" HTTP encodings.
"HttpCompressionEnabled" : true,
This appears to turn off the compression also for the dicom-web and thus stone web viewer. Thanks you very much. This reduced the “waiting for response” from multiple seconds down to 50ms, now 99% of the time is spend on downloading the data and everything is much faster and more responsive. You might consider adding to the Orthanc Book or the documentation in the config that setting "HttpCompressionEnabled" : fasle might be advantageous for setups that contain large Multi Frame DICOMs.
Scrolling through the slices is also faster (I presume because the viewer now has the uncompressed data in memory), but unfortunately still slow and very much laggy, probably because processing of a 90 MB Multi Frame DICOM and extracting the frame to display is too computationally intensive.
