WordPress Scalability

I know why I turn off many of the “tech experts” and “internet celebrities” – they’re wrong so often it makes my head spin.  Take Chris Pirillo today on Google + pitching Tiki as a CMS, as an alternative to WordPress or MediaWiki.

The statement as to why he doesn’t like WordPress was very plain: “it doesn’t scale”.

Bullshit on that I say!  It most certainly does scale and I’ve proven that over the years.  Geek.com alone used to withstand regular slashdottings, trips to the Digg homepage, etc.   The site regularly took massive traffic, although it was a long learning process to get there.

Here is what you need to know to make WordPress scale:

  • To truly scale on epic levels, you’ll need to have the ability to cluster webservers, cluster databases, etc.  Few sites really need that level of hardware, but some will.  If you do, you’ll need to drop your uploads on a common mounted drive, then use a CDN to distribute the images so you don’t really create a single point of failure.
  • You need to install and use the Super Cache plugin.
  • For massive sites, with lots of commenting, use HyperDB to separate your reads and writes.
  • Plugins: for the love of screaming monkeys, stick to only a handful of known, scalable, plugins.  Avoid anything that’s going to hit your DB every single time someone loads a page.  Also make sure the plugin obeys Super Cache.
  • Actually turn on Super Cache…really.
  • If you’re getting hammered by a traffic spike, turn on Super Cache lock down mode.
  • The real truth about WordPress scalability is this: most people don’t have hosting accounts that allow them to get traffic on this level.  Often the host will shut them down for bandwidth abuse, or simply throttle them, making it seem the system isn’t scaling.
So let’s review – scalability issue in WordPress come down to three things usually:
  • Issues with the host
  • Poor server setup
  • WordPress plugins
If you need more specifics, catch me on G+ or email me and I’ll be happy to help.

4 thoughts on “WordPress Scalability”

  1. I’m debating whether I should use custom post types to post large volumes of transactional data to the system. I’m just worried that performance will be a real dog and that maybe having bespoke tables might help me achieve far better performance but then that forces me down a much more bespoke route that I’d love to avoid.

    I’m not an expert on WordPress and having read your post I thought maybe you could spare some wisdom in the form of your point of view or a pointer to some other reading material that might help me understand performance/scalability factors in WordPress better.

  2. While I agree with most of this I do not in anyway recommend Super Cache because it is disk based (same with LiteCache as well). Once you start clustering you will invariably need memcache and at that point you should either add Batcache or W3 Total Cache. Disk based caches are for hobbyists and amateurs.

  3. When this was written, W3 Cache hadn’t been released for more than a couple months, and since I am referring to issues I’d had prior to that, W3 Cache was not an option. I used W3 Cache now, but can say that it is certainly possible to get a disk based cache to work in a load balanced environment, as I did it for this project.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>