February 26, 2011
Being the most popular CMS in the world, and a superb back end system, WordPress still has a lot to be ashamed of behind the scenes: messy code, inconsistent naming schemes, an obscure library system and awful database schemas.
A lot of this contributes to very poorly performing code – and not in the way that many of the “well designed” CMSs perform poorly (because they’ve been over-thought), but because scalability and caching has not been built in at all levels.
This article will take you through the steps of optimising an existing WordPress install to purr again, either after many years of service which have bought it to it’s knees, or a massive jump in content that’s exposed parts of your template that really slow things down.
1. Keep WordPress Up to Date
On the whole, whist adding features, the WordPress team is also is working on optimisations which you can take advantage of by moving to the latest version available. Typically we use the Subversion repositories so that it’s only a single command to bring everything in line with the latest release. You’ll also benefit from having a greater number of plugins available that can help optimise your CMS – your plugins can also be kept up to date via Subversion or the back-end system. See more on this in my post on WordPress and Subersion.
2. Use Caching Plugins
This isn’t the place to go into detail on all the WordPress caching plugins available – but many of them will get the performance you need. At Acumen we typically use W3 Total Cache due to the advanced caching options and cache database engines (it supports Disk, Memcache, APC, etc)
3. Use PHP Optimisers
Again, there are many explorations of speeding up PHP on the web. At Acumen we use APC due to its simplicity to install on Linux.
4. Tune your template
First, turn off any and all caching plugins, and use Firebug or Google Page Speed to inspect page load time. This is important because it reflects the loading time of content that may at any point become uncached (after it’s been edited, after a cache expiry, etc). If you’re finding that some of your pages are loading slowly, you’ll need to look at the exact code you’re using and see if a simpler alternative can be written. In extreme cases you might need to write your own SQL to work around WordPress’s lack of recursivity options in the available system queries, or even add your own caching to your template’s queries.
Note that browser-based analysers aren’t the only approach to analysing the performance of your template. If your server is struggling to serve your user’s requests, it’s likely the nominal load will be greater than 0 (we’re talking UNIX here, obviously). In this case, you can set a target to bring your server back into a 15-minute average of no more that 0.3.
If you’re really struggling to identify where code issues are coming from, you can consider the MySQL –log option, which will write a list of all queries it’s supporting.
5. Clean Stale WordPress Files
One great new feature of WordPress 2.6+ was that it keeps a revision of every page. You may want to remove existing revisions by deleting all `posts` with `post_type`=’revision’, and setting a template variable like the below:
That’s it for now- if you’ve any other suggestions for speeding up WordPress, leave them below and we’ll work them into this article!
January 1, 2011
If there’s two bits of software I love, WordPress and Subversion would be right up there in terms of making my life simpler, and making publishing easier. While it’s tempting to counter statements like these with a long list of problems, I’ll leave that as it is – today I want to convey a few things that helped me use the two pieces of software together.
First, the context of using WordPress and Subversion jointly is typically in making sure that customer websites are fully versioned so that we can be accountable and transparent, and equally importantly so that we can roll back in a disaster scenario.
Second, some background on our approach. We believe that when using Open Source software for customers, it’s important to strike a balance between cutting edge features and stability. We typically accomplish this by starting the project at the head revision of the software we’re using – in this case, WordPress.
Now we have a freshly checked out copy of WordPress, and we’ll want to keep it this way. If you don’t feel comfortable with leaving a repository in a certain state there are a few options here – the most obvious would be for you to maintain your own copy of the WordPress source tree (which can be useful in other ways too, for instance if WP’s subversion servers were to go down.) This can be accomplished easily using `svnsync`.
Assuming that you’re happy with your checked-out WordPress, we now want to move all the User data to one place, so that we can version it separately to the WordPress trunk. Typically, this is just the `wp-content` folder, but you may also want to version wp-config.php, .htaccess, and any other special files you’re using in the project webroot.
Your final decision on the path structure really depends on the scenario- you may want to separate out the theme directory from other ‘user content’ directories if you’re planning to open source your theme or host it elsewhere. In this case, you’d have a subversion repository containing the folders within wp-content, with a `themes` folder which will load your versioned theme(s) as an svn:externals entry.
Now, a couple of tricks – first, your uploads folder may want to be versioned. If not, you’ll want to svn:ignore it. If you do version it, you’ll probably want to svn:ignore some of it. For instance, WP2.5 onwards supports image resizing, and it uses the uploads directory also as a cache store for these thumbnails. We can ignore these thumbnails by setting the svn:ignore property on the uploads directory as follows:
Note that if your uploads folder is structured by date, these ignore settings will not persist in new directories, so I’d recommend you do not use a structured uploads folder if you are versioning it (the option titled ” Organize my uploads into month- and year-based folders”).
December 20, 2010
Subversion is a great piece of version control software, and has been at the core of all our development projects for many years. Sadly, there are a few weaknesses. Key among them is lack of obliterate support, but one that’s stung us a few times now is corrupt SVN databases.
Here’s a quick runthrough of the solution I developed to the common ‘bad transaction’ issue, that causes your repository to stop checking out/modifying certain files (typically blobs).
1. Use svnadmin verify to find your bad revision (in this example, 195)
2. Dump the first working section of the repository to a dumpfile, then dump the second section as an incremental dump onto the end of this dumpfile
3. Try to rebuild this repository by creating a new repository, and using svnadmin load to read in the newly created dumpfile.
4. It’s likely that paths can not be rebuilt, and you will see errors describing this. Use svndumpfilter to exclude the problematic paths, creating a new dumpfile for each exclusion, and repeating from step 3.
5. Replace the rebuilt repository’s UUID with that of the old repository, by using svnlook uuid and svnadmin setuuid.
6. Use svn switch to attempt to move a checked out copy to your new repository.
7. If all goes to plan, replace your corrupt repository with your rebuild, and svn switch any working copies back to their original path. Then copy back in the data that you lost in the exclusion process, commit and get on with your work.
There you go, loads of messing around to get back to square one. Once that’s done, stop using FSFS as your SVN backend, as it’s much more buggy!