Optional Redis Cache Configuration about pg_tileserv HOT 6 CLOSED

Yeah, if you're caching just for load mitigation in a high usage scenario, the global expiration time on the cache will do the trick fine.

If you're caching because tile generation is slow enough to be noticeable, and you have relatively low usage, then you want your cache to persist until it's actually invalidated by data change.

So many use cases! 😄

from pg_tileserv.

Is there a reason that using something more decoupled, like a reverse caching proxy or even a CDN wouldn't meet your needs? Squid? Nginx with a reverse proxy? Varnish?

from pg_tileserv.

I hadn't thought of that. I do use NGINX for reverse proxying, but hadn't explored its caching functionality, which I'll dig into now.

Thanks for the suggestion, and closing out the issue (looking forward to the upcoming "discussion" feature for this sort of thing).

from pg_tileserv.

I'd love to hear your experience with this approach. I think it's a reasonable approach, but I'd love to hear real-world stories of benefits/drawbacks.

The only operational drawback I can see is that an externally managed cache is hard to link up to a signal from the database when changes in a table invalidate portions of the cache. In an ideal world, insert/update/delete can invalidate the relevant tiles in a cache, but that definitely requires communication between the database and the tile cache.

from pg_tileserv.

Thinking about it, it seems like having a frequent enough cache invalidation (maybe 1-5 minutes?) should generally address that issue, per the proxy_cache_valid NGINX directive. I guess it depends on how concurrent you expect your data to be though. I'll report back when I get some time to tinker with it.

from pg_tileserv.

from pg_tileserv.