A couple of years ago, I stood up a WordPress server. I made no effort to tune it, let alone turbocharge it, which is a decision I later came to regret. If your site gets more than a few hundred hits per day, you need to tune it. If you want to get more than a few hundred hits per day, you need to tune it because Apache and MySQL’s default settings are by no means one-size-fits-all. And you can never have too much speed. There are two reasons for that: Google favors fast sites over slow sites, and Amazon found that a one-second delay in page load drops traffic by 7 percent.
There’s a lot of advice out there on tuning WordPress, some of which seems to be good, and some of it not so good.
Here are four things that I know work. I run Apache and MySQL under Linux; these tools may run under Windows or OS X too.
Stop the spambots. Keeping spam comments from appearing on your site is nice, but it’s not enough. You want your database to be serving real visitors, not processing spam (which, in my case, was well over 90% of the comments I got).
I still get spam, but this week I got two. I doubt anyone cares, because I’m the only one who ever saw any of it. But when an aggressive spambot would take hold of my site, it could chew up 50% of my CPU resources for extended periods of time, which meant those resources weren’t available for real people. That’s a problem. My longtime readers did notice that.
This non-obvious step probably made a bigger difference than anything else I did.
Optimize your database. The faster your database is, the faster your site is. The easiest way to speed your database up is to automate and schedule routine maintenance, and WP-DBManager makes it dead simple.
Installing WP-DBManager, repairing and optimizing my databases, and scheduling repair and optimization to happen on a recurring basis took me five minutes to do, and the improvement was immediate and dramatic. The plugin author recommends you do both about once a month; that’s way better than not doing it at all. A large and busy site may benefit from doing it more frequently, but at the expense of slowing the site down during those maintenance periods.
Run Apachebuddy to tune Apache. The default settings Apache gave me were set to consume 3.9 GB of memory, which is more RAM than a 32-bit x86 system can address. Never mind I also need room for a database server and an operating system. Run Apachebuddy to make sure you aren’t in the same boat.
Run MySQLtuner to tune MySQL. MySQL’s default settings weren’t quite so insane, but it was possible for MySQL to consume all of the available memory in my system too. Changing to its initial recommendations dropped memory usage way down to a perfectly reasonable 300 MB, while providing faster responses too. Talk about doing more with less.
After running it and getting memory usage down to about 300 MB, MySQLtuner started wanting to inch my memory settings higher again. That would be fine if MySQL wasn’t having to share space with Apache on the same box.
I had to run both tools a few times, change settings, and measure memory usage to find something that would give both Apache and MySQL enough space without pounding virtual memory too much under heavy load. I came up with settings that would keep them out of virtual memory entirely, but under light loads, 75% of my available memory was sitting idle. So I upped both a little bit, so they’re using about 50% of memory under light load, and under super heavy load, they might use about 200 MB of virtual memory. That seems acceptable, especially since there’s usually a spambot involved when my server gets under heavy load, and I’ve effectively blocked those now.