The tileserver is designed with a L1 (memory) and L2 (on-database) cache.
We should consider moving the tile cache to a separate database (#15) if there are performance implications to having it on the same database/cluster. But keeping it in the same place as the Macrostrat database may prove fine, so let's start there.
Of more immediate interest, there are two potential approaches to the "L1" cache. So far we have set up a mostly-transparent HTTP response cache (Varnish) in front of the tileserver, which caches a set quantity of the most recent requests. This has several characteristics:
Independent of our application code
Memory cache is specific to each pod
Cache expiry can be done by route if desired
This may not "play nicely" with current request-logging approaches (#36) without figuring out Varnish's logging system
A "memory key value store" like Redis would allow finer-grained control but be more tightly coupled to our application.
Logging and cache expiry could use reuse patterns also used for PostgreSQL-served queries
Cache could (probably) be shared between pods
This would likely duplicate a lot of the logic of our "on-database" cache, which could be good (similar logic and API) or bad (only a benefit to the extent that there is a large difference in reading a cached tile from Redis vs. PostgreSQL)
The tileserver is designed with a L1 (memory) and L2 (on-database) cache.
We should consider moving the tile cache to a separate database (#15) if there are performance implications to having it on the same database/cluster. But keeping it in the same place as the Macrostrat database may prove fine, so let's start there.
Of more immediate interest, there are two potential approaches to the "L1" cache. So far we have set up a mostly-transparent HTTP response cache (Varnish) in front of the tileserver, which caches a set quantity of the most recent requests. This has several characteristics:
A "memory key value store" like Redis would allow finer-grained control but be more tightly coupled to our application.