And we’re back again for the fourth instalment of the VPS setup guide for WordPress! Just to refresh your memories, we are setting up a VPS using the VPS.net service, optimised for faster serving of your WordPress sites.
In Part 1 we discussed the technologies used, and in Part 2, we set up Ubuntu, PHP, MySQL and phpMyAdmin. In Part 3 we completed the Nginx configuration and installed WordPress, ending up with a running WordPress site. Now it’s time to further tweak this setup.
Today we will focus on caching, which is an essential element in speeding up your site. It is important that you follow step-by-step, so if you haven’t completed the previous parts, head back to those posts before starting Part 4.
- Part 1 – Introduction & Hardware/Software Selection
- Part 2 – Setting Up Ubuntu, PHP, MySQL and phpMyAdmin
- Part 3 – Setting Up Nginx and WordPress
1 – Install W3 Total Cache
W3 Total Cache is the most complete WordPress performance framework.
It’s used and recommended by web hosts like: MediaTemple, Host Gator, Page.ly and WP Engine and countless more.
It is trusted by countless sites like: stevesouders.com, mattcutts.com, mashable.com, smashingmagazine.com, makeuseof.com, yoast.com, kiss925.com, pearsonified.com, lockergnome.com, johnchow.com, ilovetypography.com, webdesignerdepot.com, css-tricks.com and tens of thousands of others.
W3 Total Cache improves the user experience of your site by improving your server performance, caching every aspect of your site, reducing the download times and providing transparent content delivery network (CDN) integration.
Of course, there are other caching plugins, and you can find comparisons with a few Google searches, however I always use W3 Total Cache as it gives me the most flexibility in setting up what I need. Having said that, it is definitely true that it does contain many options, and can be confusing to a beginner. If you’re feeling a bit overwhelmed by the W3 Total Cache interface, check out John Saddington’s excellent guide on Tentblogger.
Once you’ve completed that guide, you can check out the folder /wp-content/w3tc/pgcache/, there should be a few files being written there, provided you have clicked around a few pages in your site. When you click on a page on your site, W3TC will cache that page in the /pgcache folder, assuming you have enabled Disk based caching.
2 – Install Opcode Caching
While installing W3 Total Cache and enabling things like disk caching and CSS + JS minification will already speed up your blog considerably, this tutorial aims to take things even further. Since we have the advantage of having full control of our VPS, we can do things which others on shared hosting might not be able to do. One of these is opcode caching. Before we start installing stuff, let’s talk about this opcode caching thing and see what it means in practice.
PHP is an interpreted language, differing from other languages such as Java and .Net, which are compiled languages. This means that each time a PHP generated page is requested, the server must read in the various files needed and “compile” them into something the machine can understand (opcode). A typical WordPress page requires more than a dozen of these bits of code be compiled.
Opcode cache mechanisms preserve this generated code in cache so that it need only be generated a single time to server hundreds or millions of subsequent requests.
Enabling opcode cache will reduce the time it takes to generate a page by up to 90%.
PHP is known for its blazing speed. Why would you want to speed up your PHP applications even more? Well, first and foremost is the coolness factor. Next, you’ll increase the capacity of your current server(s) many times over, thereby postponing the inevitable need to add new hardware as your site’s popularity explodes. Lastly, high bandwidth, low latency visitors to your site who are currently seeing page load times in the 1-2 second range will be shocked to find your vamped up site serving up pages almost instantaneously. Do I have you convinced yet? Yes? Thought so!
There are many PHP Accelerators (OPCaches) as seen on this Wikipedia list. As is common with open source products, they are all fairly similar.
Here is a list of the most commonly used caching systems:
APC will be built into PHP6, is widely used and performs brilliantly so we’re going to go with that. The others are still valid accelerators and you should feel free to experiment with them if you are so inclined, however I doubt that there will be much performance difference.
So, without further ado, let’s get cracking with APC Opcode caching!
If you haven’t yet installed APC, here is the command to get it installed:
apt-get install php-apc
service php5-fpm restart
The APC source code archive (/usr/share/doc/php-apc) includes a script named apc.php. This script serves as the administrator interface for the cache, allowing you to look inside the cache at any time to view usage or inspect cached variables. It’s a good idea to get familiar with how this works before starting to write any code.
This diagnostic script can be found in /usr/share/doc/php-apc, To begin, extract the script from the source code archive and and drop it into your WordPress site’s web root like this:
cp /usr/share/doc/php-apc/apc.php.gz /srv/www/mysite.com/public_html/
gzip -d apc.php.gz
Then, open it in a text editor and set the administrator password (you’ll find it near the top of the script).
Once you’ve got that done, try accessing the script through your Web browser at http://mysite.com/apc.php, replacing mysite.com with your domain as usual. You should see something like this:
As you can see, the script provides a birds-eye view of the current cache status, displaying general cache information, usage and statistics on hits and misses. The information is presented for both the system cache (which handles opcodes) and the user cache (which handles user variables). You’ll also see some interesting data derived from these statistics, such as the number of cache requests per second, the hit rate and miss rate.
This information is useful to understand how well your cache is working, and identify areas that are under-optimized. In particular, note the cache full count value, which indicates how often the cache has filled up; if this is a high number, it’s an indication of high cache churn and suggests that you should perhaps assign more memory to the cache.
In order to understand the benefits of APC, we need to look at two metrics in particular, as highlighted on the Themesforge Caching tutorial:
- Memory (apc.shm_size) Size
This is the most important metric. APC will store the compiled PHP code in your server’s RAM. The default size of the memory block allocated to APC is 32 MB. This is generally too low for your typical WordPress website. If you leave it at the default 32M and the cache is filled quickly, it will most likely hit 100% memory usage in a very short space of time, at which point APC will dump the complete contents of the cache. When this happens all new incoming PHP requests will be re-compiled by APC and this will cause a memory spike in itself on your server. Moreover, if you’re constantly hitting high percentiles of APC memory usage it is likely that your cache will become quite fragmented, in turn causing a performance degradation. If after a week or two you find at you’re never using more than 50% of your memory allocation you can always dial it back down. I am currently assigning 56M per site on my servers, which works just fine for me.
- Cache Hits & Misses – When a PHP request is served from your APC cache this is a HIT. When the PHP request must be loaded, parsed and compiled by PHP this is a MISS. When you first install APC and load your first few WordPress requests you will have more misses than hits – naturally as APC has never seen them before. But after a few more requests you’ll find your hits should start rising dramatically. Over time (after a day or two) virtually all PHP requests should be hits. For a typical stable WordPress website where you’re not chopping and change plugins, themes frequently, you should be getting high 90%’s for your hit ratio.
Once you understand these 2 fundamentals everything else after should be pretty straight forward. There is a lot of other fine tuning you can do to your APC install but your cache size and your hit ratio will be the main determinants of how effective APC is for your server.
Below is a typical APC configuration as suggested by the Themesforge tutorial, I’ve also implemented and can confirm that it works very well.
To edit your APC config:
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 96
apc.optimization = 0
apc.num_files_hint = 4096
apc.ttl = 7200
apc.user_ttl = 7200
apc.gc_ttl = 0
apc.cache_by_default = 1
apc.filters = ""
apc.mmap_file_mask = "/tmp/apc.XXXXXX"
apc.slam_defense = 0
apc.file_update_protection = 2
apc.enable_cli = 0
apc.max_file_size = 10M
apc.stat = 1
apc.write_lock = 1
apc.report_autofilter = 0
apc.include_once_override = 0
;apc.rfc1867 = 0
;apc.rfc1867_prefix = "upload_"
;apc.rfc1867_name = "APC_UPLOAD_PROGRESS"
;apc.rfc1867_freq = 0
apc.localcache = 0
apc.localcache.size = 512
apc.coredump_unmap = 0
apc.stat_ctime = 0
If you’re interested in what each of these values is for look no further than the main APC Runtime configuration docs.
And there we go, Opcode caching is all set up and done with! Can we continue tweaking our caching further? You bet! Enter Varnish caching….
3 – Install and set up Varnish
Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 – 1000x, depending on your architecture. A high level overview of what Varnish does can be seen in the video attached to this web page.
For this step, I am going to refer you directly to Themeforge’s excellent tutorial on setting up Varnish. This is the tutorial that inspired this whole VPS setup series here on WPMayor.com, and it contains all the useful information you need to know about setting up Varnish and tweaking it for WordPress, so I won’t be repeating the same thing here.
So at this stage we’ve set up our server with the main software components needed to run a site, we’ve installed WordPress and also fine tuned it for speed using various caching techniques. Anything else left? Sure, you can go on optimising and tweaking a VPS forever. I’ll probably be writing up another post soon with some more handy stuff and security steps to follow.
If you enjoyed this post, make sure to subscribe to WPMayor’s RSS feed.