Stream: terminology
Topic: Caching Errors
Grahame Grieve (Apr 03 2017 at 03:52):
An issue has arisen in the IG publisher, which is a heavy user of terminology services.
Grahame Grieve (Apr 03 2017 at 03:52):
in order to keep the performance up, the terminology server aggresively caches responses from the server, and editors are encouraged (but not required) to keep the cache in version control.
Grahame Grieve (Apr 03 2017 at 03:53):
the other reason was because I paid for every query out of my own pocket.
Grahame Grieve (Apr 03 2017 at 03:53):
that's not true anymore (yay Google) and some I'm considering not caching some error responses - transient ones....
Grahame Grieve (Apr 03 2017 at 03:54):
but the terminology service API does not differentiate between errors that are transient, and ones that are repeatable.
Grahame Grieve (Apr 03 2017 at 03:54):
that's because how do you, as a server author, know? ok, for some things you do. If a code system is not defined on the system, you'll always say that it's not known (at least until someone defines it)
Grahame Grieve (Apr 03 2017 at 03:55):
where as others - database down, capactity exceeded - are obviously not suitable for caching.
Grahame Grieve (Apr 03 2017 at 03:55):
does anyone have any opinions about getting the terminology service error responses to deal with this?
Jim Steel (Apr 03 2017 at 03:56):
Should be able to deal with this using response headers, right? Expires, etc?
Jim Steel (Apr 03 2017 at 04:00):
we put "Cache-Control: must-revalidate,max-age=1" on our errors at present
Jim Steel (Apr 03 2017 at 04:01):
(which is kind of turning off caching unless you optimise for ETags)
Grahame Grieve (Apr 03 2017 at 04:01):
you do that for all errors?
Jim Steel (Apr 03 2017 at 04:07):
We do that for all everything, actually. We're pretty conservative about caching
Jim Steel (Apr 03 2017 at 04:08):
If I could make that max-age=0 and still have nginx respect it, I would
Jim Steel (Apr 03 2017 at 04:11):
Actually, now you mention it, there are some things I need to fix to make that work properly...
Michael Lawley (Apr 04 2017 at 23:09):
We specify must-revalidate because its a transactional system - the code systems / value sets could be updated at any time and thus invalidate a cached expand / translate / lookup / read response. With a client that understands ETags and sends an if-none-match header, you'll get back a 304 if appropriate. So the round-trip isn't saved, but the bandwidth of sending the result is. Times drop from 100s of ms down to ~10ms
Last updated: Apr 12 2022 at 19:14 UTC
