<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 6, 2018 at 3:42 PM, PGNet Dev <span dir="ltr"><<a href="mailto:pgnet.dev@gmail.com" target="_blank">pgnet.dev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My $0.02 coming from experience building out scalable WP clusters is, stick to Varnish here.<br>
</blockquote>
<br>
Miscommunication on my part -- my aforementioned Varnish-in-front referred to site dev in general.<br>
<br>
To date, it's been in front of Symfony sites.  Works like a champ there.<br>
<br>
Since you're apparently working with WP under real-world loads, do you perchance have a production-ready, V6-compatible VCL & nginx config you can share? or point to?<br></blockquote><div> </div><div><br></div><div>Nothing off the top of my head/isn't NDA-protected ;) But basic configs will generally serve you well. Varnish and Nginx are mature, stable projects; basic proxy_pass design with Nginx + basic Varnish config and a PURGE method handler should suffice for most operations. Beyond that, tune Nginx for buffer sizes and do a bit of kernel tweaking if necessary for windowing, if you need.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
FRiCKLE's module is great, but it would be scary to put into production- have fun with that test/release cycle :p </blockquote></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yep.  Hence my question(s)!<br></blockquote><div><br></div><div><br></div><div>Right- my point is, it's not officially supported, and Nginx has no stable API/ABI. With every release you want to leverage you need to walk through your entire test/canary/B-G/whatever cycle. That's a question only you can answer, but asking about "what about X release" is fruitless because of a complete lack of ABI support. In six month's it's an obsolete question, whose only two answers are "be the developer and watching the changelog" or "compile the module, test it, and pray to the diety of your choice that it doesn't explode".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
</blockquote>
<br>
This time 'round, it's not entirely 'my' motivation; came with the job's "prefer to haves".<br>
<br>
Based, in apparently large part, on the usual use of TheGoogle; these 2 in particular:<br>
<br>
<br>
<a href="https://deliciousbrains.com/page-caching-varnish-vs-nginx-fastcgi-cache-2018/" rel="noreferrer" target="_blank">https://deliciousbrains.com/pa<wbr>ge-caching-varnish-vs-nginx-fa<wbr>stcgi-cache-2018/</a><br>
  <a href="https://www.scalescale.com/tips/nginx/nginx-vs-varnish/" rel="noreferrer" target="_blank">https://www.scalescale.com/tip<wbr>s/nginx/nginx-vs-varnish/</a></blockquote><div><br></div><div><br></div><div>Stepping back, these articles compare Nginx vs. Varnish straight-up. There is considerable difference to take into account in examining a stack leverage both.</div><div><br></div><div>And of course, always always always take into strong account the context and limitations in which these articles were written. They do not care about your particular business limitations, context, financial/resource restrictions, or anything else that makes your situation useful. A large grain of salt is always important to hold here.</div><div><br></div><div>In particular, the first article doesn't leverage keepalive (I maintain "ab" is a horrid tool in this day and age), uses a cloud service with the client living in who-knows-what-geographic/network-topology, and quite frankly was written by an author who does not focus on systems/operations. Tread wisely.</div><div><br></div><div>The second article is two and a half years old, offers no data whatsoever, and touches on a number of irrelevant topics (SSL, h2). I'd steer clear of any opinion offered here.</div><div><br></div><div>If I were you I would strongly question this "prefer to have" if the only question is manageable cache purging. :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is official support for cache purging with the commercial version of Nginx: <a href="https://www.nginx.com/products/nginx/caching/" rel="noreferrer" target="_blank">https://www.nginx.com/products<wbr>/nginx/caching/</a>.<br>
</blockquote>
<br>
Ah, so not (yet) in the FOSS product.  I see it's proxy_cache, not fastcgi_cache, based ...<br></blockquote><div><br></div><div><br></div><div>I imagine that's a question for the sales folks, outside of this list :D</div></div></div></div>