So last week was WordCamp Atlanta 2014. I gave a talk there about caching, nginx, and CDNs. It was originally intended to be a talk about nginx, Varnish, and memcache, but I ended up changing it a bit at the last minute and focusing on caching, content delivery networks, nginx, and just making WordPress fast in general.
The slides for my WordCamp Atlanta talk are posted below…. which is to say, I had no slides in the first place and it was apparently something like total anarchy mixed up with a bit of realness… I’ll call that a win 🙂
— Melanie Crissey (@MelanieCrissey) March 15, 2014
But despite the lack of slides, I still wanted to go ahead and share some notes from my talk, and the key points we covered
Not all caching is the same
There is no one size fits all solution for making WordPress fast. Different tools are solving different problems. If you want to make your website faster, you need to start by identifying what problem you’re having in the first place
Database/object/opcode caches (APC, Xcache, Memcache, etc) basically precompute results from the database and from PHP calls, respectively, and store them. Usually it stores them in memory. These can be great tools for reducing calls to the database. But you gotta worry about running out of memory, first of all, and second of all you need to be careful about stale/expired content.
Page and static asset caches
Page and static asset caches (Varnish, Batcache, etc) store copies of your web pages and return those when visitors request them, as opposed to hitting the database each time somebody wants to see a certain webpage.
Content Delivery Networks
Content Delivery Networks (CDN’s) are kind of like a page/static asset cache, but with the added benefit of geographic dispersion (read more about why that matters on my blog post about CDN’s). They also typically have longer expire times for content and give you a little bit less control over content-freshness (usually, but not without exception). They’re great for things like multimedia (video, images, etc) and static pages. But they can increase the risk of stale content, and they won’t help you very much with database-intensive applications (e-commerce, membership, events management, etc). It will offload some of the work that has to happen in order to make your website load, but it’s not offloading the part of your website that’s actually slow. Any benefit you get will be by implication, i.e., your server can focus more on the database since it doesn’t have to deal with static assets and pages… but that’s really the problem you’re trying to solve if you have a website that’s slow cause it’s hitting the database too much
Be careful with caching.
Caching by itself won’t solve every problem you’re likely to encounter with web performance.
Caching is a hammer. Not everything you’re gonna see in web performance is a nail. For example, Apache server’s default is to spin up a new thread every time someone visits your website. Caching will help a bit, in the same way a static asset cache will help a database-intensive website. But it’s not actually getting to the root of the problem. If your problem is that you have sporadic and occasionally very high traffic spikes, you want to look into alternatives to Apache, like nginx or lightpd.
Thanks to everyone who stopped by my presentation. Thanks especially to Melanie Crissey for being such a great volunteer; Mika Epstein and Russell Fair for a great pep talk the day before I presented; Mike Schroder and Lance Cleveland for some great conversation about databases in WordPress; and Nancy Thanki for getting a bunch of awesome photographs of WordCamp, and for putting up with my crap and being a great partner in general. Couldn’t have caused so much anarchy without you 🙂
For those of you who liked that nginx vs Apache paraphrase, I’ve added the source of it below 🙂
“Apache is like Microsoft Word, it has a million options but you only need six. Nginx does those six things, and it does five of them 50 times faster than Apache.” –Chris Lea.