<div dir="ltr">I ran both Varnish (for caching), Nginx (ssl offloading) for quite some time in production, but then switched to Nginx only. The main reasons being:<div><br></div><div>- The sheer amount of added context switches (proxying was done local on a cPanel box, seeing 20-30k reqs/sec during peak hours)</div><div>- Issues with managing hacks/changes for spoofing the HTTPS env in Apache, while maintaining the option of regular updates (CloudLinux ended up adding this patch for me in it's builds <a href="https://alex-at.net/blog/apache-mod_remoteip-mod_rpaf">https://alex-at.net/blog/apache-mod_remoteip-mod_rpaf</a> => <a href="https://www.cloudlinux.com/cloudlinux-os-blog/entry/beta-easyapache-4-updated-1-31">https://www.cloudlinux.com/cloudlinux-os-blog/entry/beta-easyapache-4-updated-1-31</a> to make things easier, but it was already too late as I had already jumped to Nginx)</div><div>- Having to manage two software versions, configs, auto config builders used by internal tools, etc</div><div>- More added headaches with central logging</div><div>- No projected TLS support in Varnish</div><div>- Bare minimum H2 support in Varnish vs a more mature implementation in Nginx</div><div><br></div><div>Since Nginx can pretty much do everything Varnish does, and more, I decided to avoid the headaches and just jump over to Nginx (even though I've been an avid Varnish fan since 2.1.5). As for a VCL replacement and purging in Nginx, I suggest reading up on Lua and checking out openresty if you want streamlined updates and don't want to manually compile/manage modules. To avoid overloading the filesystem with added I/O from purge requests/scans/etc, I wrote a simple Perl script that handles all the PURGE requests in order to have regex support and control over the remoals (it basically validates ownership to purge on the related domain, queues removals, then has another thread for the cleanup).</div><div><br></div><div>Hope this helps some :)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 7, 2018 at 9:12 PM, Reinis Rozitis <span dir="ltr"><<a href="mailto:r@roze.lv" target="_blank">r@roze.lv</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No real "vs" or "thing" IME.  nginx(ssl terminator) -> varnish -> nginx works quite nicely.<br>
<br>
There's also Varnish's terminator, Hitch, as an alternative,<br>
</blockquote>
<br></span>
Sure in general there is no problem offloading varnish (done it with nginx / stud / haproxy / hitch / h2o .. etc and still running several setups).<br>
<br>
But again depends on your needs and willingness to deal with larger software stack (that's why I said it's another topic) as you end up with 2+ moving parts (which have their own configuration / own resources / network buffers / sockets / timeouts etc) but obviously there are things which one does better than other (and vice versa).<br>
<br>
I just added it because you initially asked to comment on "nginx-native" approach (if we can consider a third-party (in non-commercial version) module as native)  ;)<br>
<br>
<br>
p.s. for some time varnish has http2 support .. maybe at some point in future either openssl gets cleaned-up/rewritten enough for them to link with it or they find some good-enough alternative  :)<br>
<br>
rr<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailm<wbr>an/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div>