Kvarn offers a built in cache with cache invalidation based on
kvarn-cache-control headers; and an
When creating a response, you choose how the server caches it.
The cache only caches responses with differing queries if the implementation demands.
This is due to performance reasons - if the query was to be cache, an attacker could send multiple queries and saturate the cache. We’re actively investigating how to improve on this.
The invalidation is lazy - it removes items only when trying to fetch them and they’re old. We might change this in the future, to an active system, where a Tokio timer would be triggered for each new cache item, removing it after the timeout. That would be more memory-efficient. I however prefer the lazy approach, as that’s similar to how the standard library handles collections - it never removes items.
Relation to HTTP status codes
Certain status codes are not cached. This is due to the nature of responses - if the server rejects a client due to an invalid request, that shouldn’t be returned to everybody.
The cache is limited by both size and count of responses.
File system cache
As noted by the functions in
files are typically cached.
You should use the caching function if:
- the resource is hot, the response isn’t cached, but data on the filesystem doesn’t change often.
- you’re using the same files on the FS in an API (while not caching responses).
In all other cases, don’t use the FS cache, as responses are cached.