admin-ajax.php – slow, long running time, persistant. Any solutions

I’m experiencing the same issue with admin-ajax.php. I’m just now running the reports to monitor what is going on. For me this started about 4 months ago with a WP version update. But, I cannot say they are connected. Even with switching to twenty forteen I can view the problem. I find it most noticeable under Appearances options, and it’s exacerbated by Theme Options.

I’ll happily share what I learn from it as we move forward with diagnostics.

It most definitely is related to an update.

recently WordPress Heartbeat API was introduced. This is what (on the admin side at least) is calling the admin-ajax.js which in turn I believe called heartbeat.js in the /wp-includes/js/heartbeat.js file.

If any plugin uses heartbeat for AJAX functions, that’s another call.

So I have multiple writers, they use the backend through the day and may each have multiple tabs open. Each tab starts a new heartbeat that tries to load the file every 15-60 seconds.

For some reason the admin-ajax.php file is taking a very long time to run. It might be down to the reason I have 10,000 posts in my wordpress install. I’d like to think scale wasn’t part of the issue but it probably is.

So in the heartbeat.js I saw that numbers defined the frequency of the heartbeat, so I’ve tried by changing 60 to 180 so that it runs every 4 minutes instead of 15 seconds. I don’t know if this has had any effect but I’m trying to track it.

It may not be the contributing issue in my case. I have disabled admin-ajax.php globally (with the exception of post.php and post-new.php) without any change with what I’m seeing when accessing Appearances and Theme Options- which is causing excessive “unresponsive page” browser messages. By allowing admin-ajax.php to run for both posts and new posts, the autosave option is still present. Making the customization has an obvious benefit: it becomes a lighter ajax handler. The obvious con is WP most likely be further developing (down the road) the use of the Heartbeat API to expand the core’s functionality.

For me, the issue persists. To that end, my server administrator is running diagnostic reports to understand why the call is taking so long. We’ve defined a slow query to log any calls over 1 cpu second.

Iv’e also excluded admin-ajax.php from caching to rest the results. It may not be a good idea to do this. But, I’d like to observe the differences in how much additional CPU load it creates so I have a good baseline for comparison.

If anything, I’m very systematic and practical when problem solving. ??

I wouldn’t disable heartbeat, it is quite functional and allows you stuff like quick edit and tag related stuff.

I don’t understand what in it takes so long to run. It’s fine running it every 15 seconds if it takes 1 second to run. How it’s taking thousands of seconds. I don’t know.

It’s a very, very heavy ajax handler. We don’t use tags on my multi-author news site. Since we have it enabled still for post.php and post-new.php it retains the features favorable for the writers which fits our environment, an environment which is highly customized depending on the user’s role.

It may be a matter of making changes server side. It will take some time to collect enough data, but we hope to see what is occurring in the Apache log and MySql long query logs as a tool in investigating it.

My site loads quickly on the front end. We do not see any issues with front performance, as some reports on the subject have indicated. It’s the admin side where we’re seeing issues. The “kill page” browser message is only because it’s taking too long to run the calls from admin-ajax.php and we’re only seeing this occur in one area involving themes.php created pages. And the Heartbeat cannot be disabled for themes.php at it will take a site down.

There is not one simple answer and it cannot be explicitly pinned on the release of the Heartbeat API, in my case, as we didn’t begin experiencing the problem when it was released in 3.6. It came much later with use of 3.7.x.

It’s going to be an interesting investigation.

OK I might have a potential reason for the length of time of WP-CRON.PHP

It seems that priming the cache was one of the longest running items on my site.

I’ve also managed to see that a function called google_analytics_async request was slowing down my admin-ajax.php so I’m looking into that now.

Any neus in this? Same problems!

Nothing solid but removing Varnish cache from my setup has created all kinds of speed increases across the board.

Same here, this is an issue with the wordpress core, actually two problems, onne – admin-jax.php seems to have no proper handling method in place, like enqueue or dequeue, I take it that is the reason why multiple duplicate requests on same page, second most problematic is the incredible slow response time. Sure hope there is a better explanation or way to control these out of control requests

Hey guys, Sorry to post in the same post, but having the same issue and pulling my hair out w/ no good results.

i’m also having the same issue, CPU spike for no reason with PHP5-FPM.

After disabling Varnish, my loads went up to 50!

@portoa, when you say the admin-ajax.php issue and enqueue, what is the fix for those 2 issues?