WordPress.org

Ready to get started?Download WordPress

Forums

admin-ajax.php - slow, long running time, persistant. Any solutions (9 posts)

  1. dionsis
    Member
    Posted 2 months ago #

    My wordpress install seems to be massively hampered by admin-ajax.php. It seems to be in use extremely regular and from googling around the web it seems that something as simple as leaving your admin panel open or having multiple authors in the backend can cause problems.

    I don't see how this could be sustainable, I have lots of contributors who would regularly be in the backend writing posts (for decent periods of time) and perusing and looking at others work to fix and edit it.

    In the logs it seems admin-ajax just runs and runs.

    [pool www] child 15690, script '/wp-admin/admin-ajax.php' (request: "POST /wp-admin/admin-ajax.php") executing too slow (96.950516 sec), logging
    [pool www] child 15690, script '/wp-admin/admin-ajax.php' (request: "POST /wp-admin/admin-ajax.php") execution timed out (126.950845 sec), terminating
    [pool www] child 15690 exited on signal 15 (SIGTERM) after 7962.787679 seconds from start

    So it's identified as slow at 96 seconds, times out after 126 seconds and then 7962 seconds later is terminated.

    What is in admin-ajax.php that would make it take that long to finish running and how can we get it to run faster. There has to be a better system here.

  2. leslie1019wp
    Member
    Posted 2 months ago #

    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.

  3. dionsis
    Member
    Posted 2 months ago #

    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.

  4. leslie1019wp
    Member
    Posted 2 months ago #

    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. :)

  5. dionsis
    Member
    Posted 2 months ago #

    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.

  6. leslie1019wp
    Member
    Posted 2 months ago #

    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.

  7. dionsis
    Member
    Posted 2 months ago #

    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.

  8. Willem-Siebe
    Member
    Posted 3 weeks ago #

    Any neus in this? Same problems!

  9. dionsis
    Member
    Posted 2 weeks ago #

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

Reply

You must log in to post.

About this Topic

Tags

No tags yet.