XCache and W3 Total Cache WordPress on High End Setup

Here with this website we are showing you settings with XCache, W3 Total Cache WordPress on a somewhat high end setup on Rackspace Cloud Server. Frederick Townes is somewhat known person to us, it is obvious that we might criticize a plugin or their business model, but actually he is a good person. Many years ago, it was Frederick Townes who mentioned us on W3TC’s other notes (2012) :

 

 

Definitely there are two plugins for WordPress Caching – W3 Total Cache and WP Super Cache. We also criticize Rackspace despite their excellent support. Piwik became bad because less people criticized – things are written with guide! So, Nginx – PHP5-FPM setup with 2 GB PVHVM Server as web server and 1 GB PVHVM server as MySQL Server and all possible stuffs from Rackspace. The linked Piwik guide will give you link to the other needed guides. We do not change any default files’ name. It is high end for WordPress considering the average CPU load and other metrics. Obviously it is possible to use Rackspace OnMetal with 128 GB RAM as Web Server and with 512 GB RAM as Application Server – around $2000 USD per month plus cost of bandwidth. But if you check traffic : processor core ratio, we are using high end server.

 

Why XCache and W3 Total Cache WordPress on High End Setup Needs Consideration

 

For WordPress, you should not use XCache as an alternative of Disk Cache Enhanced for Page Caching. XCache is blazing fast, but even with 128 GB + 512 GB RAM combo offer, there is enough chance of hit and miss. XCache is fast but it sucks memory and takes huge time to build the Cache. So, the place of XCache in any high end setup is for object Caching. Otherwise your Time To First Byte (TTFB) will be very poor (if you use XCache for Page Cache) :

The website in real loaded quite faster, but on computerized tests; actually it becomes bad. Somewhat good after Page Cache set to Disk Enhanced :

Keep in mind – this is a full HTTPS setup. Practically if there is a HTML page, the server will less likely to die if 200 opens one particular webpage at the same time. Unfortunately, this theory fails as during the building of cache after post publication, the rush comes on the new post. Still, it (Disk Cache Enhanced for Page Cache) is better option than remaining kind of naked. As our disk I/O is very good, read-write cycle technically becomes better with Disk Cache Enhanced. A GET request => Cache Present => Served. PHP5-FPM almost has no work. But, if you keep only XCache in front, all traffic will go through that fast cgi block of Nginx server config file. If there is no Cache, its quite difficult to logically define unlike Disk Cache Enhanced (on Nginx setup). It is not abnormal to get this kind of graph :

Only Disk instead of XCache for Object Caching is possibly a bad idea as the Hard Disk will actually be seek more and more. So the settings becoming :

The XCache thing requires further tweak.

 

XCache and W3 Total Cache WordPress : Setup

 

In Nginx Installation guide and later tweaks (search our web site with the thing you want), we actually installed XCache. If you run this command :

You will get an output like this :

With Ubuntu, you need not to fight much. You only need to locate the settings file :

You’ll get an output like this :

The last one is the file written by Frederick Townes for W3TC, only two must be commented out in this fashion :

The path of W3TC’s specific file by default Nginx setup is :

With increasing load actually a better result should be expected :

With a scalable infrastructure, good hardware, SSD, practically XCache is not required. There is no XCache :

We need X factors for a spinning hard disk, no CDN, no scalable InnoDB engine. Rest required is manual coding to decrease the number of requests, serving CSS without being a blocking element, setting the expire headers properly.