Bulk edit posts very slow performance

  • Bobot

    (@bobot)


    3 months ago

    I recently installed WP 6.6.1 on my shared host. All standard config, no plug ins. Imported about 100 posts from Blogger as a base. Attempts to do any bulk edit of posts in the Post menu is extremely slow and eventually leads to a Gateway 504 timeout. For example, this timeout occurs if I choose about 25 posts in bulk edit and simply apply the “published” option again to them. Changing any one bulk item post can take 5 seconds or more. Is this just a caveat on shared hosting? Please see detail from web host below.

    My site health info shows this but not sure it is an issue:
    Page cache is not detected but the server response time is OK Performance
    Page cache enhances the speed and performance of your site by saving and serving static pages instead of calling for a page every time a user visits.
    Page cache is detected by looking for an active page cache plugin as well as making three requests to the homepage and looking for one or more of the following HTTP client caching response headers:
    cache-control, expires, age, last-modified, etag, x-cache-enabled, x-cache-disabled, x-srcache-store-status, x-srcache-fetch-status.

    • Median server response time was 159 milliseconds. This is less than the recommended 600 milliseconds threshold.
    • No client caching response headers were detected.
    • A page cache plugin was not detected.

    Here is some site info details:
    Server architecture Linux 4.18.0-553.8.1.lve.el8.x86_64 x86_64
    Web server Apache
    PHP version 8.2.21 (Supports 64bit values)
    PHP SAPI fpm-fcgi
    PHP max input variables 6200
    PHP time limit 90
    PHP memory limit 768M
    Max input time 60
    Upload max filesize 512M
    PHP post max size 512M
    cURL version 7.61.1 OpenSSL/1.1.1k
    Is SUHOSIN installed? No

    Database
    Extension mysqli
    Server version 10.6.18-MariaDB-log
    Client version mysqlnd 8.2.21

    WordPress Constants
    WP_MEMORY_LIMIT 256M
    WP_MAX_MEMORY_LIMIT 768M

    I reached out to my web host provider and they responded with this, suggesting I contact WordPress support:

    Thank you for contacting Technical Support, I've taken a look at your WordPress install with the posts bulk update feature issue that you're having. 
    I am able to replicate the issue, it appears to take longer than 90s to complete which is why it's getting the 503 error. 
    The part that is a big a head scratcher the SQL query it runs to enumerate the posts it completes within the first second, MySQL is left untouched from that point forward, and when I do a bulk update in WordPress CLI for these posts but instead of 10, doing 100, it completes in under the 90s cut off. 
    Even then when checking the load on the server when running the bulk change within WordPress is not taxing the CPU. 
    Considering that you're using wordpress in nearly it's stock configuration I can only chalk this up to a coding error or bug within WordPress' software.

    [stimul10@ecngx308 allthingsbobot.com]$ time wp post update $(seq 400 500) --post_status=publish
    Success: Updated post 400.
    Success: Updated post 401.
    Success: Updated post 402.
    Success: Updated post 403.
    Success: Updated post 404.
    Success: Updated post 405.
    Success: Updated post 406.
    Success: Updated post 407.
    Success: Updated post 408.
    Success: Updated post 409.
    Success: Updated post 410.
    Success: Updated post 411.
    Success: Updated post 412.
    Success: Updated post 413.
    Success: Updated post 414.
    Success: Updated post 415.
    Success: Updated post 416.
    Success: Updated post 417.
    Success: Updated post 418.
    Success: Updated post 419.
    Success: Updated post 420.
    Success: Updated post 421.
    Success: Updated post 422.
    Success: Updated post 423.
    Success: Updated post 424.
    Success: Updated post 425.
    Success: Updated post 426.
    Success: Updated post 427.
    Success: Updated post 428.
    Success: Updated post 429.
    Success: Updated post 430.
    Success: Updated post 431.
    Success: Updated post 432.
    Success: Updated post 433.
    Success: Updated post 434.
    Success: Updated post 435.
    Success: Updated post 436.
    Success: Updated post 437.
    Success: Updated post 438.
    Success: Updated post 439.
    Success: Updated post 440.
    Success: Updated post 441.
    Success: Updated post 442.
    Success: Updated post 443.
    Success: Updated post 444.
    Success: Updated post 445.
    Success: Updated post 446.
    Success: Updated post 447.
    Success: Updated post 448.
    Success: Updated post 449.
    Success: Updated post 450.
    Success: Updated post 451.
    Success: Updated post 452.
    Success: Updated post 453.
    Success: Updated post 454.
    Success: Updated post 455.
    Success: Updated post 456.
    Success: Updated post 457.
    Success: Updated post 458.
    Success: Updated post 459.
    Success: Updated post 460.
    Success: Updated post 461.
    Success: Updated post 462.
    Success: Updated post 463.
    Success: Updated post 464.
    Success: Updated post 465.
    Success: Updated post 466.
    Success: Updated post 467.
    Success: Updated post 468.
    Success: Updated post 469.
    Success: Updated post 470.
    Success: Updated post 471.
    Success: Updated post 472.
    Success: Updated post 473.
    Success: Updated post 474.
    Success: Updated post 475.
    Success: Updated post 476.
    Success: Updated post 477.
    Success: Updated post 478.
    Success: Updated post 479.
    Success: Updated post 480.
    Success: Updated post 481.
    Success: Updated post 482.
    Success: Updated post 483.
    Success: Updated post 484.
    Success: Updated post 485.
    Success: Updated post 486.
    Success: Updated post 487.
    Success: Updated post 488.
    Success: Updated post 489.
    Success: Updated post 490.
    Success: Updated post 491.
    Success: Updated post 492.
    Success: Updated post 493.
    Success: Updated post 494.
    Success: Updated post 495.
    Success: Updated post 496.
    Success: Updated post 497.
    Success: Updated post 498.
    Success: Updated post 499.
    Success: Updated post 500.

    real 1m43.933s
    user 0m16.938s
    sys 0m0.708s

    You might want to reach out to the Developers of WordPress see what they suggest or at least them know that doing bulk edits is leading WordPress to lock up when attempting to do so, but that bulk edits work from CLI and when it happens there is no queries stuck in MySQL nor a high load from PHP.
    • This topic was modified 3 months ago by Bobot.
Viewing 5 replies - 1 through 5 (of 5 total)
  • Moderator James Huff

    (@macmanx)

    Is this just a caveat on shared hosting?

    More than likely, yes. Editing just 1 post can take about 5 seconds, and the bulk editor doesn’t speed up the process. Instead, it just automated the process so you can walk away and let it do its thing.

    Shared hosting providers offer finite resources that are shared between all sites hosted on the same server, sometimes thousands of sites. Therefore, in order to preserve the stability of the server and avoid those thousands of sites going offline because of one bad actor, shared hosting providers often stop processes they think are using too many resources.

    If you have 100 posts to get through, try bulk editing 25 or 10 posts at a time instead.

    Thread Starter Bobot

    (@bobot)

    Yes as I mentioned, a simple bulk edit change on 25 posts will timeout. If I do 5-10 at a time, it usually works. Also note the text from the host provider support indicating the database call updated in short time but WP hung on response.

    • This reply was modified 3 months ago by Bobot.
    • This reply was modified 3 months ago by Bobot.
    Moderator James Huff

    (@macmanx)

    WP wouldn’t hang on its own, it would only get to that point on a bulk response if it doesn’t get back what it’s expecting from the server, like if the server terminated a process.

    In this case, I recommend either better hosting or just doing 10 at a time. Ideally you won’t need to use the bulk editor often.

    Thread Starter Bobot

    (@bobot)

    Yes, bulk editing seems to be more useful now as I have the imported blog posts to clean up but probably won’t be used as much over time. I guess I was concerned how the site is going to perform in the wild if it was having performance issues with 120 posts and no eyes on it. If it’s not a known issue, I’ll have to keep tabs on it and look into more powerful hosting if necessary in the future.

    Moderator James Huff

    (@macmanx)

    Yeah, just remember that editing posts is a vastly different process than viewing posts.

    You should have no trouble fielding lots of visitors even if you have trouble bulk editing posts.

    If you do run into trouble fielding your usual audience, some optimization may be in order, and we have some general recommendations at https://developer.www.ads-software.com/advanced-administration/performance/optimization/

Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.