There were several reasons why I chose WordPress for this blog. One of the minor reasons is to prove how easily (not really) one can configure WordPress to survive what used to be called the /. effect, and what is now, in the age of Twitter and Apple mania, called a Fireballing.
John Gruber, the Philadelphia fish behind the fireballs, always has his nose in the air about WordPress. His site is static and sits on a very beefy server. It’s always fast. The same cannot be said of many self-hosted WordPress sites.
WordPress is dynamic by design. It’s extremely popular and relatively easy to use. So yet more people run it. But then they get fireballed.
Brian Stucki, the fellow behind MacMiniColo, used one of his Mac Mini’s to host fireballed.org. A Mini hosting static pages is more than good enough to survive a fireballing, and probably even a combined fireballing and /. effect.
The problem is that unless you’re a programmer or a sysadmin, configuring WordPress to survive a fireballing is too difficult.
Before installing WordPress, I installed Percona‘s version of MySQL. It’s faster, more stable, and its default settings are pretty good. MySQL’s defaults are rather poor for a WordPress-backed site. Rafe found his default setting to be 0. Percona’s default is 16 MB. (My VPS has 768 MB of RAM, Rafe’s has 512.)
After installing WordPress and loading it up with a few articles, I used ab from another computer rather far away to generate the traffic. Yes, I know bloggers, but not engineers, use ab, but I just needed to whack a blog, not correctly test Twitter. Testing 1,000 connections, each making 100 requests, I saw 22 requests per second. Not bad. But we can do better.
Next I installed WP-Cache. Yes, I know WP-Super-Cache is even better, but configuring it is more of a beast. Improvement? Indeed. 450 req/sec, up from 22. Definitely good enough to survive a fireballing.