Peer Performance Options - HTTP Keep-Alive?

Google Groups archive
1

Good Day All,
I have been actively using the peer feature more and more, looking to make sure I am using at its maximum potential, and had a question or two:

HTTP Keep-Alive - Notes as Depreciated. Is this because it is enabled by default, or a bug/issue with it?

HttpCompressionEnabled - I am compressing to JPEG2000, would anyone know if there is much need or added benefit for this?

Sending Instance/Study based - I am currently sending each instance as it is received. Any performance benefits sending it as a completed study?

Apache Proxy - Has anyone seen any options within Apache that may help with performance. (Using it as a proxy)

Anything else i’m missing?

Thanks!

2

Hello,

I have been actively using the peer feature more and more, looking to make sure I am using at its maximum potential, and had a question or two:
HTTP Keep-Alive - Notes as Depreciated. Is this because it is enabled by default, or a bug/issue with it?

This option corresponds to the “keep_alive” parameter of the embedded Mongoose HTTP server. This option should improve overall HTTP performance by reusing TCP connections:

Unfortunately, by default, Orthanc is stuck with Mongoose 3.8 for licensing issues:
https://groups.google.com/d/msg/mongoose-users/aafbOnHonkI/09MXDIy4ZcoJ

But, Mongoose 3.8 goes back to 2013, and many issues bound to keep-alive have been fixed in Mongoose since that release:

Furthermore, we have never noticed any performance improvement by using it, possibly because of the corrected issues. As a consequence, we don’t recommend enabling this feature.

However, you could give a try by replacing Mongoose with its fork CivetWeb, that is actively maintained and that might contain fixes related to keep-alive, which can be done by recompiling Orthanc using the “-DENABLE_CIVETWEB=ON” while invoking CMake. Please share your findings.

HttpCompressionEnabled - I am compressing to JPEG2000, would anyone know if there is much need or added benefit for this?

I don’t think so.

DICOM files embedding JPEG2000 pixel data would not be much further compressed with the “deflate” compression of HTTP, and would imply much increased CPU usage:

Sending Instance/Study based - I am currently sending each instance as it is received. Any performance benefits sending it as a completed study?

I don’t think so. HTTP connections are indeed independent from each other if HTTP keep-alive is turned off, which means that a new HTTP handshake for each instance send to other peers.

Maybe switching to CivetWeb could provide an advantage in that respect (check above), please share your findings.

Maybe you could also use the DICOMweb WADO-RS API to download all the DICOM instances of one completed study in one single HTTP request as a multipart message:
http://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_6.5.1

Apache Proxy - Has anyone seen any options within Apache that may help with performance. (Using it as a proxy)

I am not an expert with Apache, please check out their documentation:
https://httpd.apache.org/docs/current/en/mod/mod_proxy.html

HTH,
Sébastien-

3

Thanks! I had done a few tests myself yesterday, very basic but:

Correct on the compression. No noticeable difference.

Thank you for the information on the keep-alive. I will look into it, and will see if Apache can be offloaded for that.