status/usage of FRiCKLE/ngx_cache_purge. still reliable? alternatives?

[Robert Paprocki]

Hi,

On Wed, Jun 6, 2018 at 3:05 PM, PGNet Dev <pgnet.dev at gmail.com> wrote:

> For some new WordPress sites, I'll be deploying fastcgi_cache as reverse
> proxy / page cache, instead of usual Varnish.
>
> Although there are a number of WP-module-based PURGE options, I prefer
> that it's handled by the web server.
>
> A commonly referenced approach is to use the 'FRiCKLE/ngx_cache_purge',
>
>         https://github.com/FRiCKLE/ngx_cache_purge/
>
> with associated nginx conf additions,
>
>         https://easyengine.io/wordpress-nginx/tutorials/
> single-site/fastcgi-cache-with-purging/
>         https://www.ryadel.com/en/nginx-purge-proxy-cache-
> delete-invalidate-linux-centos-7/
>
> ngx_cache_purge module development appears to have gone stale; no commits
> since ~ 2014.
>
> What are your experiences with current use of that module, with latest
> 1.15x nginx releases?
>
> Is there a cleaner, nginx-native approach? Or other nginx purge module
> that's better maintained?
>
> Comments &/or pointers to any docs, etc would be helpful.
>

My $0.02 coming from experience building out scalable WP clusters is, stick
to Varnish here.

FRiCKLE's module is great, but it would be scary to put into production-
have fun with that test/release cycle :p

The overhead of putting Nginx in front of Varnish is fairly small in the
grand scheme of things. What's your motivation to strictly use Nginx?

There is official support for cache purging with the commercial version of
Nginx: https://www.nginx.com/products/nginx/caching/.

I've seen moderate hardware running Nginx (for TLS offload + WAF) ->
Varnish (cache + purge) -> Apache/mod_php do 50k r/s on a single node. One
would hope this suffices; it's a stable and proven stack. Again,
ngx_cache_purge is great, but any unsupported module in a prod environment
is scary when you're not writing the code. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180606/6be848d3/attachment.html>