For the majority of blogs, speed isn’t a great big deal. Efficiency doesn’t matter too much either. I’m not terribly fussed about either issue on this blog. My other blog however, gets quite a hammering now. Given the little server it is hosted on, this can cause problems. So how can you make a small server act like one of the big boys, without having to spend a fortune on upgrading?

Note: This is partially for those who host their own websites on their own web servers. You will require root access to do some of this… but not all. Even those on shared web hosting can benefit from some of these suggestions, so do keep reading!

Disks are Slow. Memory is Fast.

One sure-fire way to inject a speed boost into your WP-powered website is to move your WordPress directory from disk, into RAM. Then configure your web server to read the web site out of RAM, rather than off the hard disk. Ubuntu comes with a handy existing method for doing this called /dev/shm. Anything you put onto that mountpoint, will actually be served out of RAM rather than the physical disk. I copy (using cp -Rp) /var/www/sussexinfocus.co.uk to /dev/shm every time the server boots.

Make sure of course that if you install any plugins through the web interface, change templates or themes and so on that you feed the changes back to physical media (e.g. /var/www/sussexinfocus.co.uk) from /dev/shm when you’re done. If the server crashes or you reboot it, everything in /dev/shm gets wiped out. That wouldn’t be cool if you just spent 3 hours pefecting your WordPress setup! If you’d like a copy of my ‘init’ shell script that’ll do all this for you, drop me a comment and I’ll get back to you.

Repetitive Database Queries Are Slow. Cache is Fast.

If your server is underpowered or not powerful enough to handle a lot of traffic, you’ll find one of your bottle-necks is your database. Ramp up the query cache within MySQL by editing /etc/mysql/my.cnf
(on Ubuntu anyway), and make sure query_cache_limit and query_cache_size are somewhere around 16mb or so. If you have lots of ram to spare, ramp that up to 64mb.

Reload your MySQL server to begin with the increased cache limits. (/etc/init.d/mysql reload).

Dynamically Generated is Slow. Static is Fast.

Every time you or someone else loads a blog page, a lot happens. Your web server calls the PHP engine which runs the compiler to compile the WordPress .php files which runs the WordPress program which talks to the database server which reads (possibly) from the disk and so on. If you’re getting quite a few hits, this very simplified example of what goes on, causes things to slow waaaay down. Cut out all that by generating static copies of your posts. Visitors then talk to your web server that calls the PHP engine which runs the WordPress program that notices a cached copy already exists, cutting down on page generation and database queries.

WP-Cache is a simple to use and effective method of achieving this. If you use my RAM Store method above, your cached files will also be in RAM, doubling the benefit. Avoid WP-Super-Cache though. It’s complex, buggy, and does pretty much what WP-Cache does anyway.

PHP Compilation is Slow. Cached Opcode is Fast.

Following on from the above example, speed things up further by cutting out your web server having to compile WordPress every single time someone requests a page. PHP Accelerators store an executable cached copy of the program in memory, cutting out the need to compile it every single time. This will be one of the best speed changes you can make for very little effort. Statistics on various sites show around a 3-30x speed increase and load decrease, just from doing this. I personally recommend eAccelerator paired with Apache2.

Serving Multiple (Possibly Large) Files is Slow. Off-Site is Fast.

My other blog is a photoblog. The photographs range in filesize from 400kB to well over 1mB. Imagine having to read these off your overloaded hard disk every time you want to show it to someone. Imagine further having to tie up an apache web server process to serve each one. Multiply that by all the visitors your site gets. Slow. Slow. Slow! But, there is a solution…

Amazon S3 is an off-site, cloud-based, distributed file storage system. To cut a long story short here, use Amazon S3 to store your uploads through your blog. Check out the Amazon S3 plugin for WordPress which automates it. S3 is super cheap for what you get, and the performance increase is very noticable. You can even keep it appearing ‘in-house’ by setting up a CNAME to your storage location. Mine is static.sussexinfocus.co.uk!

Can it Really Make a Difference?

If you just do the above, then yes, it really can. My page generation times have dropped from an average of 650ms with a transfer average of 1933ms to 102ms generation time and 778ms fetch time. That’s a 600% speed increase.

If you look at it another way that is a 600% DECREASE in the time someone stares at “Web site found, waiting for reply…” in their browser, and the whole page loads more than twice as fast as it did before!

Be Realistic.

Ultimately, if you’re truly successful, no amount of optimisation will be sufficient, and you will need to look into upgrading your hardware. If you’re already struggling, then these tips will keep you going for a good while yet. If you’re designing a new blog and want to be ‘Digg proof’ from the beginning, these principles should go a long way to keeping your site up and serving requests rather than doing the usual ‘crash and burn’.

This entry was posted on Thursday, July 2nd, 2009 at 7:10 pm and is filed under Geek. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.