In a recent review from ReviewSignal, DreamPress performed significantly better than last year. This is due, in large part, to the efforts of multiple teams here at DreamHost and their commitment to improving cache performance.
DreamPress has always made use of multiple cache layers to help make your WordPress site run faster. Since caching is a large part of the benefits brought to you by Managed WordPress Hosting, we’ve continued to iterate on the types of cache we use and replaced some with others, all with improving your experience in mind.
What Is Caching?
The basic idea of caching is to store something for later use. When you visit a webpage, your browser saves copies of the file — caching it — and if you go back to the page, your browser will check if the page thinks it’s newer than its cache. If it’s not, the page loads super fast.
When you’re not using caching, your site can run more slowly because every time someone visits, the page has to be rebuilt. This is especially true with WordPress, which doesn’t use plain HTML pages but rather PHP to generate content from your database.
What Caches Do We Use?
In addition to the normal hardware and OS-level caching that’s expected on modern servers (which we also offer on all hosting plans) DreamPress 2 makes use of three separate caching layers that work in concert to improve your experience.
A front-end cache sits between your website and the Internet, saving the output of WordPress so that PHP doesn’t have to be run every single time. These caches also sit in front of Apache, the web server software we primarily use, so it keeps the server load low. This means that a visitor to your site would get a cached page without ever touching the backend, and your experience writing and editing posts will be faster.
Front-End caches can be as simple as storing the HTML output from your site on disk or as complex as storing in memory. Most WordPress users are familiar with plugins like WP Super Cache, which stores the HTML output in a cache folder and uses PHP or .htaccess to redirect visitors to the cached content. For DreamPress 2, we use Varnish as the frontend, to store the content in memory. This provides better performance for the WordPress site as well as removing the hassle of managing extra plugins.
While we’ve always used Varnish for DreamPress, we improved the cache rules on DreamPress 2 to work even better with WordPress and its myriad plugins. One of our biggest changes is that 404s are now cached. This allows a site to better withstand attacks or high traffic from bots, instead of generating that 404 page from scratch every single time.
The Varnish HTTP Purge plugin that we install for you on DreamPress allows WordPress to tell Varnish when a new page is created. New page creation, new comments, and any page or post edits will trigger Varnish and tell it to delete that cache, letting your site display the new content right away.
PHP Code/Opcode Cache
The next layer of caching we use is PHP-specific and used to cache parts of the code – called bytecode – as it’s compiled. By saving that information, we’re able to load your sites faster without making PHP run every single time. We used to use xCache for this, but as we’ve upgraded PHP to 5.5 for DreamPress 2, we were able to switch to the more robust OPcache. OPcache is included in PHP, making it reliable and dependable going forward.
After the swap to OPcache, a default WordPress install had its load drop, becoming significantly faster. HHVM, an alternative to PHP we offer with DreamPress, has the ability to cache entire compiled files to disk. It too is significantly faster than xCache, showing results similar to OPcache.
We also saw a ~15% drop in power usage for our DreamPress VPS hosts once we switched to OPcache. DreamPress 2 not only makes your site faster but it makes your DreamHost servers even greener.
The last layer of caching is tucked within WordPress itself. WordPress has its own built-in object caching system but it’s very limited, storing items in memory for a single page view. If you provide WordPress with a persistent object-caching server, it can store those items in memory across page views, which means fewer database calls and much faster load times.
Since the inception of DreamPress, we’ve used Memcached to provide this persistent object cache. In DreamPress 2, we juiced up the configuration by doubling the RAM and increasing the slab size (which defines the maximum size of a single item in the cache) from 1MB to 4MB.
While it’s true that increasing the slab size can make caching run slower, we did it in order to provide better support for customers with large wp_options tables. The options table holds the site configuration information, and because of the way it’s stored, it’s one of the largest key/value pairs that Memcached needs to store. This table can get rather large due to the manner in which some plugins and themes record their settings.
Why is it so large and why is it hard to cache? Memcached stores each option from the database in two ways: First, it caches each option setting on its own upon access; Second, it caches the whole table into a single key/value called “alloptions” in persistent cache. This lowers the number of requests and brings the most items into memory at once — at least until WordPress is able to replace alloptions with a key cache, which is a project being worked on right now.
Since an average WordPress install stores less than 1MB of options, leaving the default slab size for an item in Memcached as 1MB isn’t a problem. But not all plugins and themes play nicely with that, and in order to support larger, more diverse sites, we decided to increase the size. By changing to 4MB, we struck a balance between speed and supportability that benefits more users. This has the effect of reducing load time by seconds for these users with large wp_options tables.
What The Future Holds
We’re not done with DreamPress yet. The lessons we learn from how you, the users, take DreamPress to its extremes is helping us design and create the next iteration. We’re already working on some wonderful features we can’t wait to share with you.
But that’s another blog post all together.