What are the pros and cons W3 Total Cache?

First off, I know this isn't a WPMUDEV product but I use essentially all of WPMUDEV plugins and themes. I would like to know how this plugin plays with the great products offered by WPMUDEV.

If anyone has used this plugin, what are the optimal settings? Does it really boost performance like the plugin page says it does? How do I prevent conflicts? What are things to watch out for?

Please excuse my broad topic but I just want to learn more about caching.

Thank you!

  • Patrick

    Hiya @SqueezyDee

    My personal opinion about caching plugins (regardless of which one) is that you don't need them, and they will inevitably cause issues down the line.

    It is by far preferable to ensure proper and secure server configuration with a reputable host and, whenever possible, host on a dedicated IP or VPS.

    But our resident server guru @aecnu may like to provide some more insight into this.

  • Ajay213

    If you have some kind of 'dedicated' machine whether it is truly dedicated hardware, VPS, etc then W3 is the best caching plugin I've found as you can dedicate quite a bit of stuff to live in memory (WP Super Cache may have caught up, but when I first looked at it years ago it was much more disk based). I've seen 50-60% drops in page load times with it, even on big beefy hardware.

    And everybody needs caching at some level, if you don't have it your site will crawl to a stop, especially using Wordpress, when you get hit with some kind of big traffic. I mention that because WP is horrible about queries out of the box, a basic 2011 theme with the standard one post one comment default setting does some 30-40 DB queries to load the 'main' page, so imaging that page getting slammed by 100 concurrent users, can your DB server handle 40 x 100 queries at one time? Some can of course, but given the size of that page a few KB of cache will mean essentially only a handful of queries get run against those 100 concurrent users, and then you don't need a huge super server to serve a default WP page.

    How about things like opcode and the like, serving 'static' content out of memory will be EONS faster than PHP running code and creating an HTML file for the browser to read. Of course the question is how long to keep stuff in cache, and that will be highly dependent on the site in question, some people can get away with leaving stuff primed in memory for a number of minutes (maybe longer), some just a few seconds. Then move out to simple disk cache, where the pages are pre-rendered and simple HTML, on some sites they can sit for hours, other sites is back to a few seconds.

    But I'm ridiculously picky about performance and if my stuff isn't fully loaded in 2 seconds I'm unhappy, and the closer I get to that 1 second mark the happier I get, and those are for 'real' pages, with pictures of all sizes, lots of purdy markup and various jquery tricks, etc.

    As for the downsides, W3 is quite complex to setup in an optimal way, and not getting it all correct may mean your site sees no performance improvement at all, and in some case may even load slower than without it. So it would be something you would want to get some help with if you aren't into all the geeky aspects of it, IIRC W3 even offers to do an optimal setup on a site by site basis for around $100 and they'll go all the way up to the theme and server level for a bit more.

    Also, I don't know if it's fixed yet, but W3 and multi-DB don't play nice together.

  • aecnu

    Greetings David (SqueezyDee),

    I was pinged in here by Patrick for comment and I want to refer you to a couple articles I wrote about W3TC specific and realize though they patched the security issue - it took over a year for them to do so therefore exposing people during the whole event.

    The security article:


    The performance article from a few days of testing:


    And David, straight up sir, Go Daddy in any and all circumstances has never been known for being a performance host of any kind.

    Cheers, Joe

  • Ajay213

    Over a year, I'm not sure where that came from? The issue was reported on/around Dec 24, a patch was made public on Dec 29 with a 'hotfix' (how to re-configure plugin to avoid issue) available a day or two before that. And it wasn't a general security hole effecting every user of the plugin, it was an issue when a user setup the plugin in a specific way that exposed information (still a security issue of course, but not nearly as bad as some made it out to be).

    As for the articles, they are certainly accurate, but don't tell the whole story. I agree 100% if all you are going to do is disk based caching a site will likely see no performance benefit and will likely see a decrease in performance. Although even that isn't telling the whole story. The disk will still need to be read at some point, a web request comes in via whatever web server you want (Apache/Nginx/etc), the request then gets handed off to php, somewhere in there the PHP file has to be read from disk (or in the case of WP you will likely be reading multiple PHP files from disk), then PHP will do it's thing, hand it back off to the web server and serve the page. Disk caching doesn't really solve much of that because the web server will need to be told where a static 'cached' version of the page exists to be read. And if that process isn't as efficient as PHP (and for all the gripes over PHP it is a fairly mature product) you see the slow downs. That will turn around as traffic grows, but you have to be seeing some big traffic numbers to see it.

    But you wouldn't use W3 for solely disk based caching, the power of the plugin comes from being able to make more efficient use of say APC or use Xcache/memcached/etc, which all has to be done at a software layer, there is no hardware level web caching at the layer we're talking about here. And serving pages out of memory will blow the doors off serving a page via PHP any day of the week and twice on Sunday, I'll bet my beer money on that. :wink:

  • aecnu

    Greetings Ajay213,

    Thank you for your input which is certainly appreciated.

    Prior to the issue being reported the version in the repository was listed for compatibility of up to version 3.2.1

    I joined WPMU DEV as a regular Member in March of 2011, WordPress version 3.2.1 came out ion July of 2011: http://wordpress.org/news/category/releases/

    From that moment the version with the exploit already existed as all versions before.

    Agreed that the exploit was not reported until 2012, but it indeed existed the entire time before in all versions before and how many people became a victim of that exploit before it was publicly announced?


    So you are right, a year was accurately being kind.

    You are right that being served from memory is fast, but how many hosts offer the kind of memory to make that so? Unless the client is on a dedicated server I do not know of any that will allow someone to use enough memory to make a difference site wide, or perhaps hundreds of sites?? As is most common with hosts today?

    I provided a chart that showed the speed and how as things move through the hardware configuration.

    I have other folks that indeed migrated from other hosting platforms, WPMU DEV Members, and when they came they brought W2TC with them and when they removed it ... things got a lot faster, so much faster they wrote to me and told me about it.

    Do not get me wrong, I do believe in the hardware caching, memory caching, and most importantly compression that combines the end users computer into the delivery scheme by making them part of the network decompressing and caching pages on the end users computer exponentially adding to the system by virtue of the inclusion of the end users computer in the grand scheme of things.

    Last but not least, many folks put caching on during development and it does nothing but mess with their heads - many of them cannot even deal with browser caching much less properly configure and get a caching system to work correctly and perform with the exception of those that are already on basically crippled hosting using throttling - which in turn gives the illusion of speed.

    Personally I prefer the brute force and performance configurations over any caching system and I agree to disagree

    Once again, thank you for your input which is absolutely appreciated and certainly gives food for thought.

    Cheers, Joe

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.