Varnish Plugin for Directadmin with SSL Caching

UNIXy

Verified User
Joined
Jun 20, 2009
Messages
25
Varnish Cache for DirectAdmin

Unleach your server today! Varnish is a state-of-the-art HTTP(s) accelerator designed to handle monstrous traffic without breaking a sweat. If your server has struggled to stay up during traffic spikes or are just looking for snappy browsing, Varnish is it!

Can I try Varnish before installing the DA plugin?

So why run the Varnish plugin from UNIXy?

  • Free of charge plugin support from UNIXy!
  • Fully compatible with DirectAdmin
  • You get to keep Apache (including htaccess/rewrite rules)!
  • Lowers server load dramatically
  • Compatible with suPHP, FCGI, CGI, mod_php (dso) & all others
  • Costs only $17/quarter!
  • Found to be much faster than alternatives (Ex: Nginx, Lighttpd & Litespeed)

Here are some features:

  • SSL/TLS Caching with Termination
  • Both Dynamic and Static Object Caching
  • Auto Installation / Deinstallation
  • Environment Detection
  • DirectAdmin Integration
  • Cache Hit / Miss Statistics
  • Opt-out Domain List Served Directly by Apache
  • VCL Script Compatibility
  • Varnish Extended Support Available
  • End User Features (cache, purge, disable)

Who runs Varnish?

  • Facebook
  • Twitter
  • Tubmlr
  • NY Times
  • Answers.com
  • The Hindu
  • And many more!

Requirements:

  • DirectAdmin
  • CentOS and RHEL 5.x / 6.x / 7.x - Supports 32-bit and 64-bit
  • Python >= 2.4 (Installed by default on CentOS 5 and 6)
  • 200Mhz CPU w/ 24MB RAM for Installation
  • Apache 2.0.x or 2.2.x or 2.4.x w/ PHP
  • PCRE Lib - Auto-Installed
  • PHP Curl SSL Library

Portal Shortcuts



Cheers!
 
Last edited:
Requirements:

  • DirectAdmin
  • CentOS and RHEL 5.x / 6.x - Supports 32-bit and 64-bit
  • Python >= 2.4 (Installed by default on CentOS 5 and 6)
  • 200Mhz CPU w/ 24MB RAM for Installation
  • Apache 2.0.x or 2.2.x or 2.4.x w/ PHP
  • PCRE Lib - Auto-Installed
  • PHP Curl SSL Library

So you do not support CentOS 7?

Also is it possible to have it disabled default for all users/domains, so that each end user instead must activate it only for the domains they want?
 
Hello,

I have tried to make contact with you and/or your company. But I do not get any respons. I want to test this out for one server. Can you contact me via PM?
 
Yes ;-) but that wasn't today or yesterday. A few months ago. But they have updated the ticket now.
 
That's interesting! Can you please PM me so we can work out the details?

Thank you, but I don't see the need for any PM at this moment. However feel free to send me a PM if you feel like.

If you add the new feature, then please let us know here, then I would be interested in testing out a trial license, and hopefully buy licenses for all our servers.
 
Thank you, but I don't see the need for any PM at this moment. However feel free to send me a PM if you feel like.

If you add the new feature, then please let us know here, then I would be interested in testing out a trial license, and hopefully buy licenses for all our servers.

Fair enough.

I'm curious, is this a feature others here find useful?

Thanks
 
Last edited:
Having the option to enable/distable a feature for specific users is very useful indeed!
 
I have been reading "How do I upgrade the Varnish plugin?" at https://www.unixy.net/secure/knowledgebase.php?action=displayarticle&id=28

It says "#note that uninstalling the plugin will remove the plugin's currently-saved settings. All rules will have to be readded post update."

Question: If a end user have disabled Varnish for one domain, when uninstalling/upgrading, will the domain still be disabled or will the end user need to disable Varnish for the domain again after upgrade of Varnish plugin? (I hope not, that would not work well for shared hosting providers.)
 
I have been reading "How do I upgrade the Varnish plugin?" at https://www.unixy.net/secure/knowledgebase.php?action=displayarticle&id=28

It says "#note that uninstalling the plugin will remove the plugin's currently-saved settings. All rules will have to be readded post update."

Question: If a end user have disabled Varnish for one domain, when uninstalling/upgrading, will the domain still be disabled or will the end user need to disable Varnish for the domain again after upgrade of Varnish plugin? (I hope not, that would not work well for shared hosting providers.)

By default Varnish will be disabled for all and that setting is saved under /home/$user/varnish/. But if the plugin were to be uninstalled/installed, the settings will still be there and "memoized" and reused when the plugin is upgraded by the admin.
 
Thanks for reply, that sound good. However I have considered this now, and we are a shared hosting provider. It will not be something we would want to forceful enable for all users domains, that would create a lot of support requests. Only if you add the feature to have Varnish disabled as default for all domains and all new domains, with only the option for end users to turn it on for one and one domain, only then we would be able to use this. I hope you can add that feature? If so I would immediate buy 3 licenses.
 
Most important; does it work? Is it faster, is it better then for example Opcache?
 
@sheep,

The opcache works on PHP's side behind apache and/or nginx.

Varnish (front-end) is used to give content directly from a cache to avoid a need to make a request to apache/nginx+php+mysql (back-end). If your page does not exist in Varnish's cache a request will be passed to the back-end and here php with opcache will work.

Varnish won't speed up page generation if request was passed to php+mysql, but it might reduce time of loading content from cache.


@UNIXy,

Thanks for your work and input.

It's important to note that those top companies who uses Varnish are not shared hosting companies and they can modify caching rules even for a single page if necessary.

Shared hosting is different. Many users with many sites. Identical configuration might or not be that good. Thus I wonder how much flexible is the plugin for an individual user or site? Can one exclude pages, media content selectively from caching using your plugin? Change TTL depending on extensions? Other?
 
Thanks for reply, that sound good. However I have considered this now, and we are a shared hosting provider. It will not be something we would want to forceful enable for all users domains, that would create a lot of support requests. Only if you add the feature to have Varnish disabled as default for all domains and all new domains, with only the option for end users to turn it on for one and one domain, only then we would be able to use this. I hope you can add that feature? If so I would immediate buy 3 licenses.

Feedback like this is very useful because I don't want us gone for a couple of weeks developing and testing something you guys won't even consider touching with a 10 foot pole. So I got what you're saying so far:

0. Users can enable / disable Varnish for their account with (sub)domain "granularity"
1. Disable Varnish by default on (re)installation except when someone explicitly enables it for one or more of their domains
2. New domains will have Varnish disabled (default)

Thanks
 
Most important; does it work? Is it faster, is it better then for example Opcache?

In theory and practice, a walk down the LAMP stack will always be slower than HTTP. Meaning by the time you get to opcache (a PHP module), you've already wasted time walking down the LAMP stack. This will always be slower than getting your page/content off Varnish.

BUT that isn't a reason to yank out Opcache from your stack. Opcache will still be needed to compile and cache PHP opcode, which isn't visible to Varnish.

Thanks
 
@sheep,

The opcache works on PHP's side behind apache and/or nginx.

Varnish (front-end) is used to give content directly from a cache to avoid a need to make a request to apache/nginx+php+mysql (back-end). If your page does not exist in Varnish's cache a request will be passed to the back-end and here php with opcache will work.

Varnish won't speed up page generation if request was passed to php+mysql, but it might reduce time of loading content from cache.

Here's something interesting that's a stop gap to this issue (cache miss due to backend (ex: WordPress = MySQL+PHP) not having generated a valid page yet). We've built this very interesting cache warmer at Cachoid where visitors ALWAYS get a fresh-cached page. This isn't a stale-cached page. It's a fresh-cached page. The warmer monitors a site's pages for close-to-expire objects and then fires off a crawler to warm it up. The warmer's request gets a cache miss, as expected, but it forces Varnish to quickly expire the stale-cached page and make room for the newly generated, fresh-cached page.

So visitors to the page will almost always get content off the cache. But then you ask: what happens when the publisher updates a post or content? Cachoid has an API for that! So for WordPress there's a plugin that listens to changes and pushes them to Cachoid via the API so the warmer can do its magic.

Anyway this covers that problem case.

@UNIXy,

Thanks for your work and input.

It's important to note that those top companies who uses Varnish are not shared hosting companies and they can modify caching rules even for a single page if necessary.

Shared hosting is different. Many users with many sites. Identical configuration might or not be that good. Thus I wonder how much flexible is the plugin for an individual user or site? Can one exclude pages, media content selectively from caching using your plugin? Change TTL depending on extensions? Other?

I hear you! Our other-control-panel (you know which one) plugin has this functionality already. Meaning users are able to adjust varnish cache behavior down the the URL of the domain. So yes it's doable. Not to mention this is already possible with Cachoid. You get one dedicated Varnish instance per website with controls for URL caching etc.

But I'm going to work on this so the controls are available in DA next.

Thanks!
 
Feedback like this is very useful because I don't want us gone for a couple of weeks developing and testing something you guys won't even consider touching with a 10 foot pole. So I got what you're saying so far:

0. Users can enable / disable Varnish for their account with (sub)domain "granularity"
1. Disable Varnish by default on (re)installation except when someone explicitly enables it for one or more of their domains
2. New domains will have Varnish disabled (default)

Thanks

Thanks! Just want to make sure I don't misunderstand you, and you don't misunderstand me:

I am not sure what "granularity" means here. But all I would need is to be able to have Varnish disabled as default for all existing and new domains and subdomains, so that end users that want to use Varnish on one or more domain, can enabled it themself for the domains they want.

It seems what you list (0, 1 and 2) is what I want and need. And would love to be more competitive in my business by offering my shared hosting clients the option to enable Varnish for the domains they like. Please be aware that we offer each customer account in DirectAdmin with a high limit of addon domains. We do not need to be able to disable Varnish on account basis, only to have it being disabled as default on all domains in every accounts, so customer can choose to enable it on some of the domains they want it on.

I am sure you understood me correct. You got my hopes up now! :) Please reply to this thread when/if you add this feature. It would be great to offer Varnish caching!
 
Here's something interesting that's a stop gap to this issue (cache miss due to backend (ex: WordPress = MySQL+PHP) not having generated a valid page yet). We've built this very interesting cache warmer at Cachoid where visitors ALWAYS get a fresh-cached page. This isn't a stale-cached page. It's a fresh-cached page. The warmer monitors a site's pages for close-to-expire objects and then fires off a crawler to warm it up. The warmer's request gets a cache miss, as expected, but it forces Varnish to quickly expire the stale-cached page and make room for the newly generated, fresh-cached page.

So visitors to the page will almost always get content off the cache. But then you ask: what happens when the publisher updates a post or content? Cachoid has an API for that! So for WordPress there's a plugin that listens to changes and pushes them to Cachoid via the API so the warmer can do its magic.

Anyway this covers that problem case.

So, for hosting company's that are running WP, Magento, Joomla, Varnisch Cache is not doing much to speed up websites? I need Cachoid to fix this issue? I see that it isn't a good solution for hosting companys. We need to find a caching program that speed up websites, maybe Varnish, maybe Redis, I dont know.
Yeah, I've I want this, It needs to disable for all users first, the users may need to decide if they want to use this.
 
Last edited:
So, for hosting company's that are running WP, Magento, Joomla, Varnisch Cache is not doing much to speed up websites? I need Cachoid to fix this issue? I see that it isn't a good solution for hosting companys. We need to find a caching program that speed up websites, maybe Varnish, maybe Redis, I dont know.
Yeah, I've I want this, It needs to disable for all users first, the users may need to decide if they want to use this.

I mentioned Cachoid as example of a working solution as a platform that's in the cloud. It's already out there and works.

But my goal from this quick discussion we're having here is to get feedback from the DA community in order to make the DirectAdmin Varnish plugin do what you guys need it to do. And so this is very helpful for the direction of the plugin.

Keep the comments / questions / suggestions coming please.

Thanks
 
Back
Top