How time is spent on a compex page

The two areas where performance problems with WordPress plugins are most common are custom filters/actions and database queries. WP-Profile is a plugin that helps you find such problems.

Actions and filters

WordPress has an intricate system of actions and filters which is used all over the place: to convert : ) into , to make links clickable and to handle the login procedure are just some examples.

Every action and filter is a hook that allows plugins to call custom functions and easily change or override default behavior. That is very useful.

It also makes it easy to really ruin performance as some common filters are called a hundred times or more for more complex pages, making small inefficiencies add up really quickly.

Unfortunately there are no good ways to keep track of the performance impact of individual filters. It is possible to profile the whole system using for example XDebug and *Cachegrind like I did in an earlier post but it is a lot of work and often overkill during plugin development.

Database queries

Database queries in stock WordPress are highly optimized. So much so that they usually only takes a few percent of total time. It is, however, very easy to change this and even seemingly simple queries can take surprisingly long time. By defining SAVEQUERIES in wp-config.php WordPress will record all queries and how long they took to execute in $wpdb->queries.

WP-Profile

WP-Profile is a small plugin I’ve written to use when developing plugins and modifying WordPress. It keeps track of all calls to actions/filters and presents it in an accessible fashion together with query information collected through SAVEQUERIES. It requires that you are comfortable making minor changes to core WordPress files to set up. It is for testing only. You can download it here.

This is the result on stock WordPress for a rather complex page with a lot of comments. Sort tables by clicking on table header (thanks to JQuery TableSorter):

We need to whitelist which get_locale() calls we filter: load_plugin_textdomain() yes, get_bloginfo() no.

For the future I’m hoping to get a new filter to use.

The major focus of this release is to handle multi-locale correctly — for example if you have one of the multi-language plugins, or if you use different languages on different installations on same host.

This was actually quite a bit of work to get working correctly for Shared Memory. Shared Memory objects doesn’t actually get deleted until every reference to the object is closed, from potentially multiple concurrent page load.

Change Log

Version 1.1

• Rewritten to cache multiple locales separately
• Split out admin functions into separate file
• Handle old SHM with questionable delete behaviour by relocating as necessary.
• Add storage debug info link
• Do not default to any specific storage type, make user choose
• Tell admin when something is wrong (also better error handling).
• Added plugin localization
• Added Swedish translation

A simple tool to benchmark web performance is Apachebench — which comes bundled with the Apache web server. To understand how a system as a whole performs you’ll need something more advanced but to just test how long it takes a page to load it works fine.

The graph above[1] expands on where I started profiling the WordPress regression. I’ve added the full 10 post frontpage and a single larger page — with rather lousy performance — and the work so far to remedy it which looks alot better.

Most of the performance back in just a handful of patches:

• #10972: no need to sanitize a post more than once (merged in 12062)
• #10971: translation performance when doing nothing (similar patch merged in 12080)
• #10987: improve wptexturize() performance (merged in 12084)

Still on list of suspects: wp_filter_kses() (though #10751), wp_widget_init()

[1] Numbers are total page load time average of 100 single threaded connections with a clean WordPress install, time is in milliseconds.

I’ve been benchmarking stock WordPress today to get performance numbers for the Cache Translation Object plugin. As I had things set up for it I also tested  the latest major releases – unmodified, clean installations – and found a 40% regression when going from 2.7 to 2.8.

Update: what I measure here is basically the clean startup time, which doesn’t say what the final effect will be on your site with a real theme, plugins and, you know, actual content.

There is often a battle between features, complexity and performance. This unfortunately natural tendency prevalent among programmers should however not result in such a drastic regression.

Update 2: More on this here.

Profiling Performance Regressions

There are a lot of changes in any major release of  a project the size of WordPress so finding the actual culprits in these cases are not always easy — though in this case some of it turned out to be surprisingly simple.

One way to find performance problems is to profile the two versions and compare. Here you can see lists of the cumulatively most expensive functions with 2.7 to the left and 2.8 to the right:

WordPress 2.7 vs 2.8 Profile

I’ve marked some interesting parts in the 2.8 profile. What you want to look for are functions that takes proportionally longer to execute and figure out why. KCachegrind (or WinCachegrind) gives many helpful views of call-chains and such things.

In this case the yellow-marked functions are calling the red-marked translation functions which suddenly consumes major resources. Doing nothing, it should be noted as the stock install doesn’t need anything translated.

A victim of Abstraction

So the first, and largest, culprit turns out to be this piece of code:

function &get_translations_for_domain( $domain ) {
	global $l10n;
	$empty = &new Translations;
	if ( isset($l10n[$domain]) )
		return $l10n[$domain];
	else
		return $empty;
}

Not setting up and calling an calling an empty Translations object increases performance again by 17%.

The rest of the regression seems to be mostly caused by changes in sanitize_post(), wp_widgets_init and sanitize_bookmark_field(), which I’ll look at next — tomorrow.

Anyone testing WordPress performance?

Update: With two patches we get back half of the lost performance.

Update 2: More on this here as noted above.

Using WordPress translated to your own language results in a surprisingly large performance cost. In my tests it took twice (or four times!) as long for an unmodified WordPress 2.8.4 start page to load when using a localized WordPress.

Translating a lot of text in an user friendly fashion is hard to do efficiently.

But there are things we can do to make it a lot less painful. Most of the time is actually spent when WordPress reads the MO files containing all text to translate and structures it into the l10n object to prepare for the translations to come. On each page load.

The obvious solution is to cache the resulting object. So I did.

The major focus of this new version is to protect the user login names of privileged users from discovery. Which, it turns out, is a lot of work to do correctly.

It includes optional restrictions on password reset attempts and new user registrations. The plugin also helps you see and modify the various names Wordpress keep for each user. By default Wordpress uses the user login name to construct author archive URLs, nickname, displayname and so on.

It also allows you to change the URL name of users. I actually find it rather strange that there is no way to change it in stock WordPress.

Remaining on the todo list: Translations, the readme.txt, some documentation, and some further testing.

Screenshots of new settings: 2.8.4, 2.5

When working on profiling a Wordpress install I found, to my surprice that for a 400 comment post the single most expensive thing was translating smilies to pictures — 55% of time to create the page!

Apart from sending a patch fixing this (which went into Wordpress 2.8) I also made a small plugin to use before the new version was available.

It is no longer useful as everyone should be using a modern Wordpress version.

It can be found here.

The major focus of this new version is to hide the username of privileged users. Which, it turns out, is a lot of work to do correctly.

It includes optional restrictions on password reset attempts and new user registrations. It also lists any privileged users whose username as the various names displayed on the blog. Which by default is all of them as Wordpress default uses the username to construct author archive URLs, among other things.

Largest missing piece is functionality to modify username (which might possibly be dangerous to do) and “nicename” (which might invalidate previous author archive URLs).