Hello,

On Thu, Nov 23, 2017 at 11:52 AM, Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Thu, Nov 23, 2017 at 10:24:19AM -0600, Andrei wrote:
>
> > > > - Does anyone have any recent working documentation on supported
> > > > modules/Lua scripts which can achieve wildcard purges as well as
> specific
> > > > URL purges?
> > >
> > > Cache purging is available in nginx-plus, see
> > > http://nginx.org/r/proxy_cache_purge.
> >
> > I'm aware of the paid version, but I don't have a budget for it yet, and
> > quite frankly this should be a core feature for any caching service. Are
> > there no viable options for the community release? It's a rather
> pertinent
> > feature to have in my transition
>
> I'm aware of at least one 3rd party module from Piotr Sikora,
> https://github.com/FRiCKLE/ngx_cache_purge. I've never tried to
> use it, and AFAIK it doesn't support wildcard purges. It is
> mostly known to developers as a hack that starts segfaulting on
> unrelated changes in proxy module, so obviously enough I can't
> recommend using it.
>
>
Thanks for mentioning the segfaulting issues, definitely not something I
want to run into. I saw that one, and some more details with Lua in these:

https://scene-si.org/2017/01/08/improving-nginx-lua-cache-purges/
https://scene-si.org/2016/11/02/purging-cached-items-from-nginx-with-lua/
http://syshero.org/post/68479556365/nginx-passive-cache-invalidation

From what I'm seeing available, it looks as though my best bet is Lua, or
pushing all the purge requests to a custom backend service that's going to
queue/handle the file removals. Redis tracking also comes to mind since I'm
going to be doing live stats for the traffic so that's another hop I have
to factor in. With these options I'm thinking of doing a cache zone per
domain, or perhaps group of domains. Are there any performance impacts from
having for example tens or hundreds of cache zones defined?

Note though that I personally think that cache purging is
> something that should _not_ be present in any caching service, and
> I wouldn't recommend using nginx-plus functionality either.
> Proper controlling of cache validity times is something that
> should be used instead. This is what happens in browsers anyway,
> and trying to "purge" things there won't work.
>

I'm sorry but I strongly disagree here. Every respectable CDN service which
offers caching, also offers purging. People want their content updated on
edge service when changes are made to their application, and they want
their applications to be able to talk to edge services. Take a busy news
site for example. When a tag/post/page is updated, they expect viewers to
be able to see it right then and there, not when cache expires. If they
wait for cache to expire, they lose viewers and $$ due to delays.


> > > Note well that by default nginx respects what is returned by the
> > > backend in various response headers, and proxy_cache_valid time
> > > only applies if there are no explicit cache validity time set, see
> > > http://nginx.org/r/proxy_ignore_headers.
> >
> > So to override the ttls set by the backend, I would have to use
> > proxy_ignore_headers for all headers which can directly affect the
> intended
> > TTL?
>
> Yes, if you want to ignore what the backend set. In many cases
> this might not be a good idea though.
>

I understand why it's not always a good idea. I have numerous checks and
balances accumulated over the years at the moment which I'm working on
porting over. Overriding backend cache headers on a granular level is
something I enjoy :)


> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx