<div dir="ltr">Hello,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 23, 2017 at 11:52 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<span class="gmail-"><br>
On Thu, Nov 23, 2017 at 10:24:19AM -0600, Andrei wrote:<br>
<br>
> > > - Does anyone have any recent working documentation on supported<br>
> > > modules/Lua scripts which can achieve wildcard purges as well as specific<br>
> > > URL purges?<br>
> ><br>
> > Cache purging is available in nginx-plus, see<br>
> > <a href="http://nginx.org/r/proxy_cache_purge" rel="noreferrer" target="_blank">http://nginx.org/r/proxy_<wbr>cache_purge</a>.<br>
><br>
> I'm aware of the paid version, but I don't have  a budget for it yet, and<br>
> quite frankly this should be a core feature for any caching service. Are<br>
> there no viable options for the community release? It's a rather pertinent<br>
> feature to have in my transition<br>
<br>
</span>I'm aware of at least one 3rd party module from Piotr Sikora,<br>
<a href="https://github.com/FRiCKLE/ngx_cache_purge" rel="noreferrer" target="_blank">https://github.com/FRiCKLE/<wbr>ngx_cache_purge</a>.  I've never tried to<br>
use it, and AFAIK it doesn't support wildcard purges.  It is<br>
mostly known to developers as a hack that starts segfaulting on<br>
unrelated changes in proxy module, so obviously enough I can't<br>
recommend using it.<br>
<br></blockquote><div><br></div><div>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:</div><div><br></div><div><div><a href="https://scene-si.org/2017/01/08/improving-nginx-lua-cache-purges/">https://scene-si.org/2017/01/08/improving-nginx-lua-cache-purges/</a></div><div><a href="https://scene-si.org/2016/11/02/purging-cached-items-from-nginx-with-lua/">https://scene-si.org/2016/11/02/purging-cached-items-from-nginx-with-lua/</a></div><div><a href="http://syshero.org/post/68479556365/nginx-passive-cache-invalidation">http://syshero.org/post/68479556365/nginx-passive-cache-invalidation</a></div></div><div><br></div><div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Note though that I personally think that cache purging is<br>
something that should _not_ be present in any caching service, and<br>
I wouldn't recommend using nginx-plus functionality either.<br>
Proper controlling of cache validity times is something that<br>
should be used instead.  This is what happens in browsers anyway,<br>
and trying to "purge" things there won't work.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> > Note well that by default nginx respects what is returned by the<br>
> > backend in various response headers, and proxy_cache_valid time<br>
> > only applies if there are no explicit cache validity time set, see<br>
> > <a href="http://nginx.org/r/proxy_ignore_headers" rel="noreferrer" target="_blank">http://nginx.org/r/proxy_<wbr>ignore_headers</a>.<br>
><br>
> So to override the ttls set by the backend, I would have to use<br>
> proxy_ignore_headers for all headers which can directly affect the intended<br>
> TTL?<br>
<br>
</span>Yes, if you want to ignore what the backend set.  In many cases<br>
this might not be a good idea though.<br></blockquote><div><br></div><div>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 :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
--<br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div></div>