WordPress MU

Got an interesting one for you.

WordPress MU 1.5.1 (upgraded from 1.3.3)
Subdirectory mode.

Actually reading the blogs is fine and all the pages are served quickly. When I go into the Dashboard, the root blog (WebLog Central) runs fine but it seems to take its time whenever I switch to another user's blog.

Any ideas??

Just realised I wasn't particularly clear:

It's not just the Dashboard but all the Admin pages that are experiencing this slowdown.

If I access the WebLog Central SiteAdmin, everything's fine but when I switch to one of the sub-blogs, the SiteAdmin can take nearly a minute to make it's mind up before showing me the page.

I'm experiencing this problem too. MU 1.3.3 was running lightning fast on our server. When I upgraded to 1.5.1 the admin panel became really slow. I'll click a link and it'll do nothing for about 5-10 seconds and then it'll load the page quickly.

Have you looked in your server logs for any clues?

Wasn't able to get the server logs. In the end, I ended up nuking the entire install and reinstalling 1.3.3 from scratch then restoring the blogs from backups.

Have you tried an object cache? In MU 1.5.1 the file cache is disabled by default but I linked to a replacement plugin at the end of the README.txt

Mine speed increased loads when I put the object file cache back in. That would be worth a look as the new readme.txt file has it in there.

Edit - Donncha responded with the same....

Trent

I just looked at my error log and it's full of these:

[Wed May 14 22:56:07 2008] [error] [client 12.34.56.789] WordPress database error Table 'database.wp__options' doesn't exist for query SELECT * FROM wp__options WHERE option_name = 'siteurl' made by get_blog_option

Do you know anything about this? I will disable all my plugins and see if that could be causing it.

I'm looking at that SQL query and it looks like it's inserting an extra _ in the table name i.e
wp__options rather than wp_options.

In reply to donncha et al, I didn't try an object cache as I had the club's chairman bleating in my ear about the problems so I went with a quick and dirty fix.

Did a bit of digging around my servers. Looks like my host hasn't enabled MemCache, eAccelerator or XCache so I'd be restricted to file-based Object caching.

wp__options...

options is a blog table, not a global one. Missing is the blog_id, to make it wp_X_options.

Just to tie in, this thread and this one: http://mu.wordpress.org/forums/topic.php?id=8245

Are probably related.

Yeah, I know that it's missing the blog_id but I don't know why or where the failing get_blog_option() is being called.

Can anybody help me troubleshoot this?

I think the blog upgrade script isn't being called correctly. Look in admin.php and change the code at the top so it only uses snoopy, and not fopen. If you not sure how to do this, just replace the fopen() line with the following 3 lines taken from the same file:
require_once('../wp-includes/class-snoopy.php');
$client = new Snoopy();
@$client->fetch( get_option( "siteurl" ) . "wp-admin/upgrade.php?step=1");

That did it. Thanks!