Dashboard slow with 2.7.

[astereo]

Not exactly sure where this bug is coming from, but it causing server usage to spike to 100% and takes an incredibly long time to load. I update the nightly daily and have noticed no improvements.

It seems to be affecting Apache: 2.2.9 and/or PHP: 5.2.6.

More info:
​http://wordpress.org/support/topic/215026

[mrmist]

Is the dashboard slow for all users or just admin level users? Does it speed up if you hide any of the objects?

Do you have anything special in your .htaccess files?

Anything in the server error logs?

[markjaquith]

Are any other admin screens noticeably slow?

[DD32]

I've found anything with comments on it tends to cause my local machine to spike up, As for the dashboard, A fair ammount of processing seems to be related to the latest comments.

[DD32]

I've found anything with comments on it tends to cause my local machine to spike up

I'm talking about admin-side stuff there; And only noticed now that this ticket was raised.

[pdreissen]

It is faster when a 'normal' user with editor rights is logged in. However it takes 5+ seconds for these type of users, and still php goes 100% on the server during these 5 seconds. It is idd slower when a user with admin rights is using the dashboard

[astereo]

[All these responses have to do with beta 3]

@mrmist - I created a subscriber account and gave that a test with the same (slow) results. Nothing special in the htaccess besides a couple rewrite rules for moved around links. Also, no errors related to Wordpress in the logs either.

@mark - Every page within the admin loads at about the same speed..the links to some to load initially, instead they stall for a few seconds, the page starts to load, and then loading will stall again for ~10 seconds at about half way in the status bar. This is a clean install with no comments and only one post, and no plugins (including Akismet) enabled. Hopefully some others from the thread will come over and post any findings they have to help narrow this down.

[sivel]

I ran a test on my local machine and did not notice any spikes in CPU while loading wp-admin. On my local install I am using PHP 5.2.4 and Apache 2.2.8. Load times were under 2 seconds.

On my production site I was running htop while accessing wp-admin and noticed a spike of approx 9% cpu usage. On my production site I am using PHP 5.1.6 and nginx. Load times were under 5 seconds.

I can not duplicate what is being reported here.

[astereo]

@sivel - As stated, it appears to be affecting Apache: 2.2.9 and/or PHP: 5.2.6. Most people aren't experiencing this I don't think, but myself and pdreissen both have the same apache and php version numbers leading me to think the issue is related to that. I've updated the nightly's daily in hopes of seeing improvement and there hasn't been any. Specifically the problem is 100% the dashboard as a whole - the frontend + login screen load lightning fast, but once you click submit and begin logging in, everything is downhill. This is even with Gears enabled.

[pdreissen]

If a developer wants to check on this. I have created two subdomains on my server installed with Wordpress 2.6.3 and the latest Beta (nightly). Send me an email and i will send you the login of those 2 subdomains, so you can check yourself. It is painfull slow in 2.7!

[ryan]

I looked at pdreissen's setup and it is indeed unusually slow. There's not much I can do from the end of a browser, however. Try installing the Dump Queries plugin to see if a slow query is at fault.

​http://plugins.trac.wordpress.org/browser/dump_queries/trunk/dump_queries.php

Read the note at the top of the plugin about defining SAVEQUERIES. The plugin appends query information to the page source. View the page source for a slow page and note the query times.

[ryan]

Also, look in the options table at the "cron" field. Does it have a non-empty serialized array in it? Do you see lots of requests for wp-cron.php in your access log?

[astereo]

While you wait for some of this responses, here's some of mine:
​http://www.astereostudio.com/experiments/28results.html

[ryan]

astereo, that's way too many queries. It looks like the cache isn't actually caching. Are you using the default cache, or do you have a custom cache backend installed at wp-content/object-cache.php?

[astereo]

Nope, nothing special - just a clean 2.7 install
For comparison 2.6.3 put up 31 queries in only 0.416 seconds. I wonder if pdreissen will see similar results?

[astereo]

For additional comparison of 2.6.3 / 2.7 the post screen on 2.6.3 came in with 23 queries in 0.480 seconds.

[ryan]

Your cache is definitely broken somehow. The options table and the usermeta table should be queried only once.

[ryan]

Does copying wp-includes/cache.php from 2.6.3 into your 2.7 install help?

[pdreissen]

Were are the queries saved ? I can't seem to find this!

[DD32]

Were are the queries saved ? I can't seem to find this!

See this comment by ryan: ​http://trac.wordpress.org/ticket/8229#comment:10

[pdreissen]

I hope this is ok :)

​http://wp27.notes-it.nl/results.html

[ryan]

Actually, I think this is a matter of non-existent options and usermeta causing lots of extra queries. Working on a patch.

[ryan]

(In [9871]) Add option defaults. Add arg to get_user_option() to avoid querying options table if user option is missing. see #8229

[ryan]

That should reduce the number of queries a fresh install does. Hopefully it will help performance a little.

[pdreissen]

Don't know what happend, updating to 9871 did not resolved the issue. Updating to the last build (WordPress 2.7-beta3-9909) did resolved the issue on my installation. Everything is fast now! Thanks!

[ryan]

You were experiencing #8347. With the fix for that plus the query improvements done here, I'm marking this as resolved.