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

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.

Any neus in this? Same problems!

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