Caching: varnish vs nginx

[custer]

Hi everyone,

We have multiple requests from multiple sources about officially supporting varnish in Plesk (and the corresponding request is pretty popular on Uservoice). There's also a certain amount of discussion that we're better off enabling caching in nginx. We'd like to discuss this with you guys -- which caching solution you'd prefer and why? Please let us know and vote on the poll. Thanks!

 

[Dx3webs]

With magento 2 now supporting varnish out of the box this would be great for us. We hack varnish into the mix when needed but it is a pain.

 

[fschubert]

Varnish is a lot more powerful than nginx. Varnishs configuration allows for more fine-tuning and header manipulation.
That said I realize that you cannot make plesk configure all aspects of varnishs VCL configuration. I would like to see basic Varnish support, enable/disable varnish caching on a per-vhost basis. Maybe even simple header modification like add/remove headers. Everything else should be the admins job.

With those basic options, most websites will see a performance boost, when the websites place their headers smartly (i.e. no cookies when they are not needed).
For all other cases there should be a big textbox for the admin to insert custom config per vhost, so the whole VCL is available if needed.

Basically all I want is an easier way to implement Varnish on Plesk servers, as it is a little tricky right now. Nginx would still be needed to terminate HTTPS

 

[Tozz]

I think this would be very difficult to implement properly in Plesk as a 'out of the box' working service. Varnish isn't a 'plug and play' service for a website. It requires quite a bit of manual tinkering. Each customers has different whishes for what he would like Varnish to cache. e.g. we have customers explicitly asking us to disable caching of .js files, because they frequently update them, while another customer wants us to cache their .js files.

Same goes for images that can change often (eg. 'this site has been scanned by product X on xx-xx-xxxx and was found clean' images) or stuff like that.

A client might want a certain WordPress plugin to not be cached, because they use it for SEO / analytics purposes.

I think Plesk should implement features that are easy to work with. A lot of the requests on Uservoice are about issues relativly easy to resolve by hand (e.g. GUI for automated updates, which can already be done by unattended-upgrades on Debian using CLI). Or things like replacing SSL certificates on mail services, which can also already be done manually in the CLI. The same goes for questions asked on Plesk forums. Most questions are pretty basic stuff, which any hosting provider should be able to solve on their own. So it looks like a lot of Plesk users are really quite novice and lack experience with Plesk and especially Linux in general.

So, since most of the requested features on Uservoice are for features that can be done manually by any somewhat experienced administrator and most questions on the forums are also pretty obvious questions, I feel implementing Varnish, which will almost always require quite advanced configuration is a bit too steep for most of Plesk' customers.

 

[Tozz]

@fschubert: I would recommend Pound for SSL termination. Smaller footprint, and does exactly what you want. Also easier to configure as a SSL termination service than Nginx.

 

[Terry Majamaki]

As someone who hosts many sites and administers them via the wonderful Plesk admin, I am by no means a system or Unix admin. I do enough to get around but will resort to real help from a Unix admin when needed. I've heard great things about Varnish and often wondered if it would ever come on a future Plesk update. Would it make our sites that much faster? That being said, I never realized that it would an option of nginx or varnish, that the two don't run together. Seems like it would be great for those of us who don't fully understand the wonderful tech that makes our websites run to get some better education so we understand that adding something like varnish is more complicated to setup and configure or could cause more problems. From my perspective, as much as I would like to have it, I would probably avoid it if it's not just turn it on and enjoy, but too complicated to configure and requires fine tuning for each site (which is probably a better way to do it if you know how). Then again, I'm up for learning something new if there is a dramatic payoff in the performance of our sites.

 

[trialotto]

@custer and @Everyone,

The question

We'd like to discuss this with you guys -- which caching solution you'd prefer and why?

is essentially not a valid question, when comparing Nginx and Varnish.

Simply stated, Nginx and Varnish are two solutions for entirely different goals: Nginx is a (reverse or forward proxy OR a light-weight, fast web server), while Varnish is primarily intended to provide a caching mechanism with some analogy to a proxy.

The combination of Nginx and Varnish is a bad combination.

The use of Varnish alone is really not desirable, since there are better alternatives, in the form of Memcached or Redis Cache.

Even though Nginx natively supports

a) disk based caching, AND

b) memory based caching, via Memcached,

it still does not imply that we can "simply compare" Nginx with Varnish and just make a choice.

In essence, one has to compare Varnish with all other caching mechanisms available.

I am pretty sure that all benchmarking tests will lead to the conclusion that a website on a properly configured web server will do best with Redis Cache.

However, as far as I know, there is not yet a rock-solid Redis module for Nginx, but that is "work in progress" and, moreover, simple workarounds exist.

Combining all of the above mentioned information and the power of Nginx directives (and possibilities to use memory based caching mechanisms with Nginx), the following applies:

1) the essence of Nginx is that its (relatively unlimited) power is underused in Plesk (and by most people),

2) the essence of Varnish is that it is "just another form of caching", that does not play well in any Plesk based setup,

3) the essence of caching is that most people are translating the "need for speed" to a rather (mostly unnecessary) complex setup,

and so on.

The conclusion should be that the current question will result in answers that are not really related to the question of "what is the most performant caching mechanism".


The questions should rather be:

- "How can the Nginx directives be used to make use of a performant caching mechanism?"
- "Should some caching related Nginx directives be part of the default Nginx configuration in Plesk?"
- "In which cases should one actually use caching mechanisms?"
- "In which cases should one apply caching on the side of the web server or on the side of the proxy?"
- "In which cases should one resort to other caching mechanisms, such as Varnish?"


My personal conclusion is that Varnish should never be part of the default Plesk stack, since it is pretty sure to cause many issues, for many (evident) reasons.

My personal opinion is that the factual underusage of Nginx in the current Plesk stack should be investigated, since that would prevent questions like the current one.


Regards......

 

[Liew CheonFong]

NGINX caching. I prefer keep things simple. NGINX can do what varnish do and more. Plus, varnish doesn't support http2, which make http2 setup complicated.

 

[doubouil]

I've managed to implement nginx proxy cache in an administrable way on my Plesk 12.5. Here's how it work :

• I customized the nginxDomainVirtualHost.php template thanks to the custom folder. Since it's PHP and simple string outputting, the hardest part is not to screw up the indentation and closing brackets.
• The PHP code looks for specially named json file in the root folder of the vhost. If found, it uses all the settings of the JSON to output more options :
  • activate the proxy cache, set its config like cache_key, how to bypass/disable...
  • You can set up some custom location to handle folders and files distinctly. The main goal is to enable proxy caching of these locations with some altered parameters per location.
    
  • Some extra config like global gzip
  • Force HTTPs
• To use it you just have to drop the JSON in your root folder and regenerate the nginx config. Debugging can be done with the Troubleshooter extension and via CLI. Since the JSON contains the (sub)domain, having the same root folder for multiple vhost is not an issue.
• I think you have to disable the checkbox in nginx config management of the vhost, so it means all the config is file based
• File based = git friendly, and I tried to generate the JSON via the CMS but I had trouble with slashs escapement.

The result are fantastic and I managed a ~500ms response time on a heavily customized Drupal 7 hosted on a cheap server, all in HTTP/2 and full HTTPs. I only glimpsed at how much Nginx can do for you, but Plesk doesn't allow for complex modifications.

So I'm neutral about Varnish, I know it have much more settings to tweak how it works. I'd say it's quite an advanced feature, so it should be a module and not out of the box. Since the people using it would be experts, a simple UI/CLI command to set a config file should be enough. For Nginx specifically, it'd be nice to be able to setup some out of current scope config : the proxy cache declaration needs to be outside of the server directive, and the bypass if in it but not in a location.

Last but not least, I haven't implemented any cache purging mechanism so I manually delete everything in the proxy cache. I found an article explaining you can decode the URL path from the MD5 filename of the cache file, but I don't have an highly updated content so it doesn't bother me. I also found that there's a Purge module for Nginx, which is not shipped with Plesk.

I'd happily discuss my implementation and share my code to the nginx adventurers out there, but be warned it's not a state of the art setup, just a functioning hack.

 

[trialotto]

@custer and @everyone,

Due to the latest post in this topic thread, I want to point out some more detailed information about Varnish.

Varnish only has (very) experimental support for HTTP/2 and only in version 5.0 (not before).

Moreover, Varnish did not support HTTPS in Varnish releases before version 5.0, which version 5.0 only contains minimal TLS support.

That always has been a structural design choice, due to specific viewpoints of lead developers for Varnish (and I must admit, I do agree with Poul-Henning Kamp to a large degree).

In fact, Varnish only used to support HTTP/1.1, implying that HTTPS support was often achieved by putting HAProxy or Nginx in front of Varnish, to function as "SSL/TLS offloader".

In conclusion, I am pretty sure that it is not the time and place to compare Nginx and Varnish.

Nevertheless, the above conclusion can change in due time, but that would be very unlikely, given the fast evolution of Nginx.

Regards.....

 

[IgorG]

Varnish only has (very) experimental support for HTTP/2 and only in version 5.0 (not before).

Moreover, Varnish did not support HTTPS in Varnish releases before version 5.0, which version 5.0 only contains minimal TLS support.

But according to Poul-Henning Kamp they are going to complete full HTTP/2 support in spring 2017. Not too long to wait.

 

[trialotto]

@IgorG,

Correct, HTTP/2 is not yet fully supported.

And in spring 2017, there is still a huge difference between Nginx and Varnish.

We can never forget that Varnish is in the line of caching mechanisms such as Redis Cache and Memcached, with this difference that Varnish requires to function as a reverse proxy in order to perform properly (and very efficient) as a caching mechanism.

In my rule book, that is both "odd" and "old skool", in the sense that if one wants a specialized server for caching, one should not have a proxy function added to it.

That used to be a big advantage, but nowadays it is completely different.

Consider an ecosystem based on Docker or any other container service: any implementation of Varnish would be odd and impractical.

Consider the Plesk ecosystem: unleashing the full power of Nginx would make any implementation of Varnish rather obsolete.

In essence, Poul-Henning Kamp has reluctantly caved in to the pressure of HTTP/2 advocates, making Varnish drifting away from a past, in which Varnish actually added value.

In the meantime, Nginx has been evolving rather quickly, with all Nginx Plus features rapidly being implemented in the open source variant of Nginx.

Again, Varnish and Nginx are rather not comparable: they are apples and pears, similar, but not comparable.

Regards......

 

[DerDanilo]

Varnish can be setup via Docker now. Maybe Plesk can make it possible to integrate this via some option that then triggers an automated process to setup a Varnish instance locally/remotely and provides/shows the corresponding option to use for websites.

 

[layerwire]

Would be nice to have both options Nginx and Varnish. One of our shared clients wanted today Varnish caching.
Found this topic in the end. I think this not so critical, but would be nice to have at some point.

 

[DerDanilo]

Would be nice to have both options Nginx and Varnish. One of our shared clients wanted today Varnish caching.
Found this topic in the end. I think this not so critical, but would be nice to have at some point.

You can use docker now if you require varnish, should work. Never tried it myself though.

 

[trialotto]

Would be nice to have both options Nginx and Varnish. One of our shared clients wanted today Varnish caching.
Found this topic in the end. I think this not so critical, but would be nice to have at some point.

@NKV

The combination of Nginx and Varnish on the same system, as a mutually exclusive alternative is not recommended at all.

Moreover, where Varnish used to have some advantages over other "caching mechanisms" in the past, these advantages are mostly vanished by now.

Or must I say "varnished by now"? After all, it is the design structure of Varnish that killed those "old" advantages.

I would strongly recommend to read up on the (excellent) ability of Nginx to cache, have a look at: A Guide to Caching with NGINX and NGINX Plus - NGINX

Nevertheless, one should always keep in mind that "caching" is a "work-around" of the problem of too much server-side rendering of web pages (for instance, sometimes it is better to simply create some plain old html files, as opposed to server-side rendering of PHP scripts and store the endresult in cache).

In short, if any caching actually is required, then there is always the option of using caching via Nginx.

Hope the above helps a bit.

Regards

 

[Juanzo]

I'd go for NGINX cache to simpify things; it's already available without any need of docker.

Being able to easily configure settings for all domains or for specific ones (like enable cache for all except specific sites) would be a big plus.

 

[garcue]

I think varnish is much better, but in my case, we use plesk to give hosting service to clients who just know how to use nginx. The basic configuration of the varnsh cache system (VCL) is much more complex than the basic configuration of nginx. So I think the two options should be included if possible, but if I stick with one of those two, I would prefer nginx.

 

[Sergio Manzi]

I always thought running Varnish in the same box as the web server was a bad idea, but I'm open to understand this is not the case...

 

[usertesting]

As someone who hosts many sites and administers them via the wonderful Plesk admin, I am by no means a system or Unix admin. I do enough to get around but will resort to real help from a Unix admin when needed. I've heard great things about Varnish and often wondered if it would ever come on a future Plesk update. Would it make our sites that much faster? That being said, I never realized that it would an option of nginx or varnish, that the two don't run together. Seems like it would be great for those of us who don't fully understand the wonderful tech that makes our user testing websites run to get some better education so we understand that adding something like varnish is more complicated to setup and configure or could cause more problems. From my perspective, as much as I would like to have it, I would probably avoid it if it's not just turn it on and enjoy, but too complicated to configure and requires fine tuning for each site (which is probably a better way to do it if you know how). Then again, I'm up for learning something new if there is a dramatic payoff in the performance of our sites.