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):

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.