Caching and Orthanc

We are starting to discuss development of a web app for Orthanc and we intend to make ample utilization of caching, local and public.

Right now we have not been successful in putting a cache in front of orthanc explorer, it maybe incorrect configuration on our part but we think it has a lot to do with how it is designed.
So we haven’t tested much, but we believe orthanc rest api behaves well with a cache, is that true?
Will it understand if-modified-since requests? What will it do?
I mean, in most of ours installations both the public cache and orthanc will sit in the same network, even if Orthanc understands an if-modified-since and decides sends a 304 it will gain us no performance if behind the scenes it took the same amount of work from orthanc to reach that conclusion. Most of the time we are talking very small json, so sending it or a 304 doesn’t differ much in bandwith and lattency, but if it has a way to know the object has not been modified without comparing than it would be a great performance enhacement since they are a lot of requests.

What about the POST requests, we are leaning on using heavilly the /tools/find api to do searches does orthanc behave the same way in regardas to caching for POST and GET requests?

In general, any toughts on our idea to use caches in this way?

Hello,

So we haven’t tested much, but we believe orthanc rest api behaves well with a cache, is that true?

Yes, one can assume that the result of most GET requests can be cached. Indeed, as any other medical information system, Orthanc subscribes to a CRD approach (“CRUD without update”) to ensure traceability. This means that DICOM resources won’t be altered between two successive GET calls (of course provided the resource is not deleted).

However, there are some (rare) exceptions. For instance, I think about the “LastUpdated” field in the generic information about some patient/study/series/instance, that is transparently updated as new instances are received. Another one is the “/changes” endpoint that warns about changes in the content of the DICOM store. I think that for most applications, this is not a big deal.

The most problematic part might be with the “/patients”, “/studies”, “/series” and “/instances” that will change as new DICOM files are received. Any serious caching system (such as Varnish Cache) will allow you to introduce such exceptions, for instance setting the lifetime of such cached objects to several seconds.

When it comes to POST/PUT/DELETE, cacheability can obviously not be assumed.

Will it understand if-modified-since requests? What will it do?

Simple answer: Orthanc does not support “if-modified-since”. In general, Orthanc does not handle or set HTTP headers for caching.

If needed, the support of the HTTP headers for caching could be introduced with a plugin that would hook all the REST calls:
https://orthanc.chu.ulg.ac.be/book/developers/creating-plugins.html

What about the POST requests, we are leaning on using heavilly the /tools/find api to do searches does orthanc behave the same way in regardas to caching for POST and GET requests?

The particular “/tools/find” URI will not modify the content of the Orthanc database, so it is safe to assume that two successive POST requests with the same body against this URI will lead to the same results (as long as no DICOM file was received in between). Once again, your caching system should be able to introduce such an exception, saying that this POST will not alter the result.

I use the POST convention for “/tools/find” to indicate that searching resources is a time-consuming process, whereas GET calls are almost immediate.

In general, any toughts on our idea to use caches in this way?

I think this is an interesting approach, and I think many Orthanc users would love to hear your feedback: Do not hesitate to contribute to Orthanc by sharing your experience with caching!

Personally, I would notably love to have instructions explaining how to setup Varnish Cache in front of Orthanc.

HTH,
Sébastien-

Thanks for the prompt response.
In a way a plugin means more work to get it all working, but it will also mean we will be able to optimize more for “if-modified-since” and other scenarios.
The “LastUpdated” is actually how we intend to implement “if-modified-since” support, Orthanc will check if the LastUpdate is greater than the header serve if true, 304 if false.
We are testing NGINX for caching, but the experience could be adapted for Varnish, as soon as we fully understand the need configs we’ll write instructions.

Great, let us know once you have news! :slight_smile:

Regards,
Sébastien-