Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#8229 closed defect (bug) (fixed)

Dashboard slow with 2.7.

Reported by: astereo Owned by:
Milestone: 2.7 Priority: high
Severity: normal Version: 2.7
Component: Administration Keywords: dashboard, slow, lag, php, apache
Focuses: Cc:


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:

Change History (25)

comment:1 @mrmist7 years ago

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?

comment:2 @markjaquith7 years ago

Are any other admin screens noticeably slow?

comment:3 @DD327 years ago

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.

comment:4 @DD327 years ago

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.

comment:5 @pdreissen7 years ago

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

comment:6 @astereo7 years ago

[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.

comment:7 @sivel7 years ago

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.

comment:8 @astereo7 years ago

@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.

comment:9 @pdreissen7 years ago

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!

comment:10 @ryan7 years ago

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.


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.

comment:11 @ryan7 years ago

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?

comment:12 @astereo7 years ago

While you wait for some of this responses, here's some of mine:

comment:13 @ryan7 years ago

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?

comment:14 @astereo7 years ago

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?

comment:15 @astereo7 years ago

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.

comment:16 @ryan7 years ago

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

comment:17 @ryan7 years ago

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

comment:18 @pdreissen7 years ago

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

comment:19 @DD327 years ago

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

comment:21 @ryan7 years ago

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

comment:22 @ryan7 years ago

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

comment:23 @ryan7 years ago

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

comment:24 @pdreissen7 years ago

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!

comment:25 @ryan7 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.