Update: As of today June 10, 2011, I have retested W3 Total Cache, and found it is still a terrible plugin. Not only is it a memory hog, but it is extremely difficult to configure, and does not work properly when connecting to a content delivery network (CDN), even when using origin pull. W3TC uses more than double, and even triple, the CPU cycles, and more than double the RAM that WP Super Cache consumes. WP Super Cache has now added the ability to use a CDN, and it works right out of the box. WP Super Cache is much faster, and uses far less resources, plus it is easy to configure, and it simply works. All the extra features available in W3TC are completely unnecessary, and will only slow down your page loads, and eat up server resources. I tested W3 Total Cache against WP Super Cache on a dedicated server with a blog getting 38 million page views per month, so the traffic was heavy. WP Super Cache handled the traffic without any problem, and plenty of resources to spare. When testing W3 Total Cache under the same conditions the CPU cycles shot up more than 3 times, the RAM consumption more than doubled, the disk cache was much slower, the Memcached and APC implementations were extremely slow, and even the graphs for Memcached recording reads and writes were very different, in a bad way, compared to the same graphs using the WordPress drop-in plugin Memcached backend for the WP Object Cache written by Ryan Boren. The web hosts claiming W3 Total Cache is much better than WP Super Cache should be viewed with suspicion since they make money when you purchase more RAM and more CPUs to keep your site running. It has been a know fact for many years that WP Super Cache helps do more with less hardware even on shared web hosting to save money, but perform better under higher loads. The bottom line is, W3 Total Cache will cost 2 to 3 times more money for hardware to handle the same traffic as WP Super Cache.
Frederick Townes, the W3TC author, has provided some people with paid for support when they’ve had problems with his plugin. I believe this practice of charging for advanced support is unethical when his plugin continues to be plagued with so many problems. After reading my fact based opinion of his W3TC plugin, and my opinion that charging anyone to support a plugin that is riddled with bugs is unethical, Mr. Townes attacked me with profanity and hateful comments through my Facebook account. Although I remained civil, Mr. Townes got more and more threatening, so I decided to check and see if he had problems like this before. I found he sued CompUSA for race discrimination, but was eventually fired for work related performance issues. The court dismissed the case finding no evidence of any discrimination, but plenty of evidence of work related issues. Click here to read the court filing along with the court order at the bottom. Mr. Townes is now threatening me with legal action for saying that charging people for advanced support of his plugin is unethical, when his plugin has so many bugs that performance is an issue that requires better code and not paid support. Mr. Townes denied, in our Facebook exchange, that he provides paid support related to his plugin, which is a lie. Only 3 weeks ago WordPress.org member PLLMedia left a message on the W3TC support forum regarding his purchased support for W3TC. Click here to read the comments from PLLMedia who paid $150 for W3TC support, and didn’t receive a support response. The unhappy customer said:
“I would suggest that anyone considering paying for support think twice about it. We sent w3-edge $150 through the plugin and all I got was an email from Paypal saying our payment was received on May 10th. I’ve since sent two emails to the support email listed on the paypal receipt, one email at the contact form on w3-edge.com, and even left a voice mail after looking up their number on jigsaw. It’s now May 20th. I haven’t heard from anyone there as to when, if ever, they plan on doing anything with our site. Apparently they don’t care. Seriously, I understand people get busy, but take five minutes to send me an email following up.”
The next WordPress.org member papek said in the next thread comment, “I always thought, there is a strong reason why the config side of things of the plugin are so puzzling and unclear. It must be income, logically. Perhaps lots of money and lots of orders, understaffed as well (could explain it perhaps?) I am planing to pay for the support too.”
Two weeks ago Mr. Townes replied to the complaining customer saying:
“PLLMedia, what is your email address? No one seems to be able to imagine getting hundreds of emails almost everyday. Each one requiring some actual thought and investigation to reply to.
Mr. Townes has a habit of making excuses for not fixing his plugin and blaming the problems on the users. It appears he also is too busy replying to those asking for free support to provide $150 worth of paid support. I have grown tired of Mr. Townes excuses for not fixing the core functions in W3TC, his personal attacks on me, and his threats.
In my opinion, Mr. Townes has a lot of personal issues, as well as professional, which I was not happy to learn about today. In my humble opinion it would be best to avoid W3TC now and in the future, since the author has such a negative attitude, and appears to believe he is the only person that can understand how his plugin works. The fact is there are plenty of other free plugins out there to solve performance issues for WordPress blogs such as WP Super Cache, and Batcache, just to name a few. Those authors do not have attitudes of supremacy. Although it may seem like W3TC has a ton of features, 95% of those features actually slow down blogs and are loaded with tons of bugs. The old rule “Keep it Simple Stupid” applies to all plugins, most especially W3TC, which is far from simple, and is so complicated no one seems to be able to configure it without problems. Most of those problems are in the plugin itself, but the author has a habit of blaming those problems on the users claiming they don’t understand how his plugin works. Users should not have to understand. Good programming makes it easy to use a plugin. It is best to avoid W3TC to avoid problems of every kind imaginable.
In reading other articles, and comments on those articles, it appears under real world blog testing most people agree that WP Super Cache is better, faster, and cheaper to run than W3 Total Cache:
Use WP Super Cache for WordPress speed, not W3 Total Cache

I’ve been using WP Super Cache for several years with WordPress to help handle high volumes of traffic, and it has done a great job. WP Super Cache is a static caching plugin for WordPress that generates html files that are served directly by Apache without processing comparatively heavy PHP scripts. WP Super Cache can also be configured to serve the static html files by Nginx, but the setup is a bit more time consuming.
A few days ago I heard about a new WordPress caching plugin called W3 Total Cache, which claimed to literally do-it-all. The author implemented every speed enhancing feature he could think of, and then added even more. W3 Total Cache claims to offer the following features and benefits:

Improved progressive render (non-blocking CSS and JS embedding)

Transparent content delivery network (CDN) support with automated media library import

Bandwidth savings via Minify and HTTP compression (gzip / deflate) for HTML, CSS and JS

Minification (concatenation, white space removal) of inline, external or 3rd party JS and CSS with scheduled updates

Caching of RSS/Atom feeds (comments, page and site), URIs with query string variables (like search result pages), database objects, pages, posts, CSS and JS in memory with APC or memcached or both

Increased web server concurrency and reduced resource consumption, increased scale

Reduced HTTP Transactions, DNS lookups, reduced document load time

Complete header management including Etags

Optional embedding of JS just above

Besides uploading and activating the W3 Total Cache, you’ll also need to install and setup either Memcached, or APC, but the plugin author leans heavily towards Memcached.
Memcached would be our choice if we had to choose between Memcached and APC. What is Memcached? Memcached iis a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load. The downside to using Memcache is that it runs as a demon on a set port, so it is open to security attacks on your server on that port, so it’s good to turn on your firewall to protect that port.
A much better object caching system is Xcache, which doesn’t need to run as a demon, and in my opion is far better than Memcached and APC in most server environments. I’ve run Xcache under extreme server loads, and it didn’t even hiccup, plus there’s no port to worry about securing.
I spent a full day setting up, configuring, and testing W3 Total Cache, and Memcached. I compared the size of the files downloaded by my readers, the speed the files were transferred, and both the CPU load and RAM required.
The performance of W3 Total Cache was not much different than WP Super Cache in serving pages. The huge difference I saw was on the server side. The CPU load increased exponentially from 20 times higher to even higher at times. I was forced to cut my testing short, and both turn off Memcache, and remove the W3 Total Cache WordPress plugin comletely. I tested version 0.7.5.
In my opinion the W3 Total Cache plugin needs to address performance issues on the server side before it is ready for mass use.
I’ve since gone back to using WP Super Cache, and everything is running smoothly again with little CPU load. The Apache web server can serve and compress static html files very efficiently, without the huge, and unnecessary, increased CPU load caused by W3 Total Cache. There appears to be little need to have a plugin like W3 Total Cache. There is a better way to build a high performance web server, with far less server load, that I’ll discuss in another article.