Avoiding Nginx restart when rsyncing cache across machines

Peter Booth peter_booth at me.com
Fri Sep 14 01:22:16 UTC 2018

One more approach is to not change the contents of resources without also changing their name. One example would be the cache_key feature in Rails, where resources have a path based on some ID and their updated_at value. Whenever you modify a resource it automatically expires.

Sent from my iPhone

On Sep 13, 2018, at 4:03 PM, Lucas Rolff <lucas at lucasrolff.com> wrote:

>> How does one ensure cache consistency on all edges?
> I wouldn't - you can never really rely on anything being consistent cached, there will always be stuff that doesn't follow the standards and thus can give an inconsistent state for one or more users.
> What I'd do, would simply to be to purge the files whenever needed (and possibly warm them up if you want them to be "hot" when visitors arrive), sure the first 1-2 visitors in each location might have a bit slower request, but that's about it.
> Alternatively you could just put a super low cache-control, when you're using proxy_cache_background_update and proxy_cache_use_stale_updating, nginx will ask the origin server if the file has changed - so if it haven't you'll simply get a 304 from the origin (if the origin supports it) - so you'll do more requests to the origin, but traffic will be minimal because it just returns 304 not modified (plus some more headers).
> Best Regards,
> Lucas Rolff
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

More information about the nginx mailing list