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:

- The sheer amount of added context switches (proxying was done local on a
cPanel box, seeing 20-30k reqs/sec during peak hours)
- 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
https://alex-at.net/blog/apache-mod_remoteip-mod_rpaf =>
https://www.cloudlinux.com/cloudlinux-os-blog/entry/beta-easyapache-4-updated-1-31
to make things easier, but it was already too late as I had already jumped
to Nginx)
- Having to manage two software versions, configs, auto config builders
used by internal tools, etc
- More added headaches with central logging
- No projected TLS support in Varnish
- Bare minimum H2 support in Varnish vs a more mature implementation in
Nginx

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).

Hope this helps some :)


On Thu, Jun 7, 2018 at 9:12 PM, Reinis Rozitis <r@roze.lv> wrote:

> No real "vs" or "thing" IME. nginx(ssl terminator) -> varnish -> nginx
>> works quite nicely.
>>
>> There's also Varnish's terminator, Hitch, as an alternative,
>>
>
> Sure in general there is no problem offloading varnish (done it with nginx
> / stud / haproxy / hitch / h2o .. etc and still running several setups).
>
> 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).
>
> 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) ;)
>
>
> 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 :)
>
> rr
>
>
> _______________________________________________
> 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