(Sebastien, I have mailed you directly, but I thought this topic might be of interest to others as well, not trying to put on pressure!).
We have an install of 0.8.3 freshly compiled/installed on our server, proxied via apache (apache takes care for credentials and ssl + it integrates with our other intranetparts in this way) ... everything works ok (viewing, uploading) but:
downloading a ZIP takes a _very_ long time. I see Orthanc move to the top of the 'top' list presumably collecting and zipping the archive. Up until the point that users click away or they experience a timeout.
Does anyone else experience this? Is there a hook to maybe pre-create the ZIP? Or is this simply a consequence of proxying via apache?
Thank you for your ideas and help in advance, regards,
Vincent
P.S. I will now make the apache timeout larger to see if this at least will give me the zip.
Because of its lightweight architecture, Orthanc is not focused on the user experience, but rather on providing the best out-of-the-box support of the DICOM format and protocol through its embedded database, its REST API and its Lua automation engine. Orthanc must be thought of as a core, administrative-level component upon which more advanced, user-friendly layers can be built.
In your case, creating a ZIP file is indeed a time-consuming operation. This should not be a consequence of Apache proxying. To put it into perspective, try and create a ZIP file from a CD that contains the medical images stored in Orthanc with Microsoft Windows: You should obtain a running time that is similar to that of Orthanc.
If user experience is important in your scenario, you should wrap Orthanc into a custom Web framework (such as Ruby on Rails or Django) or a native application framework (such as .NET, Java or Qt). This framework would allow you to implement a “non-blocking compression queue”, downloading each DICOM instance individually from Orthanc, then compressing each of them using the chosen framework, eventually presenting the user with the resulting ZIP file when it is ready. If load balancing is properly implemented, this would allow to keep a highly responsive system, even in the presence of multiple users. But such an advanced user interface is clearly out of the scope of the core, open-source Orthanc server.
HTH,
Sébastien-
PS: Depending on your goal, you could also consider developing some Orthanc plugin to (1) transparently pre-compress each incoming DICOM instance (e.g. with gz), then (2) implement a mechanism to concatenate all these pre-compressed instances as a single compressed file (e.g. with tar): http://codeproject.com/Articles/797118/Implementing-a-WADO-Server-using-Orthanc
Hello Sébastien,
thank you for your input. I have come back to this project and compiled/upgraded orthanc. Wiggling some details on the apache config (ProxyTimeout) made it better and also _disabling_ the keepalive in the orthanc.json config file.
I understand what you saying and get within which scope you want the orthanc project to be.
Here is the config I use with apache. I use this so I can do the SSL and Authentication via Apache, and not from Orthanc. Orthanc runs as http client, and allow only localhost to access orthanc:
# orthanc json config file snippet:
/**
* Security-related options for the HTTP server
**/
// Whether remote hosts can connect to the HTTP server
"RemoteAccessAllowed" : false,
// Whether or not SSL is enabled
"SslEnabled" : false,
# apache config file, but you might want to put it in your vhost directly
# orthanc will show up under https://my.server.com/pacs/