[wp-hackers] max performance tuning in wp

Andras Stracz shikakaa at gmail.com
Wed Aug 4 13:44:37 UTC 2010


Sorry for the wall of text. There's tldr at the bottom!

I'm working a WP 2.9 installation that has 600 posts, 200 pages, 1000
attachments, 1200 posts in a custom post type, 150 categories and about 200
- 200 in 2 custom taxonomies. There are about a dozen plugins installed but
they are generally for shortcodes. The server running this installation is
fairly powerful / vastly oversized, we use less than 1% of the CPU on
average and other resources are also plentiful. Most visitors are logged in.
The html code is optimized (minimized, concatenated, gzipped, cached
properly, etc).

The issue we ran into is that WP got slow over the previous few months, and
by now each pageload takes about 500ms. WP Tuner confirmed the total DB time
for the avg 50 queries on each page no more than 15ms and a couple of XDebug
profiles confirmed the problem is with WP core itself. Since a lot of
plugins add functionality for shortcodes and most users are logged in,
traditional caching plugins are just about useless for me. XCache's op code
cache and object cache help only about 20% (stored in memory only so it
basically acts as tmpfs as well).

So far there were 2 major wins:

parse_request for instance runs a 10000+ foreach loop based on the
get_option('rewrite_rules') field, which was 1.5MB. The sad part is that
most of the items in this array were for features we don't use, like feeds,
comment feeds, standalone attachment pages, trackback urls, paged comments -
most of which is explicitly turned off in WP so it's a nice bug that the
rewrite rules still exist for them. This was easy to fix using an earlier
thread here on WP hackers.

Using the persistent cache of XCache, I've also added fragment caching,
based on the transient API's guide on the wiki, by surrounding expensive
blocks with the code below. It is fairly successful, most pages now load
under 110ms and with proper wp_cache_flush() calls, there are no downsides
I'm aware of.

if (false === ($code = wp_cache_get('top-menu','menus') ) ) {
//html code and whatever generates it
$code = ob_get_contents();
wp_cache_set('top-menu', $code, 'menus', 7200);
echo $code;

The problem is the first 40ms of this avg 110ms is already spent before
loading functions.php and 65ms before it gets to any output in get_header();
I'm looking for tips and tricks that I can try to get rid of as much of this
as possible.

TLDR; how can I continue improving performance? I have a hard time figuring
it what are the key slownesses before the theme folder's function.php is


Andras Stracz

PS: if anyone's interested, I have before and after dumps from xdebug,
viewable with cachegrind-like software. 655kb zip: http://bit.ly/c615E7

More information about the wp-hackers mailing list