• Anonymous User 15141300

    (@anonymized-15141300)


    I have set up a multisite network (subfolders) with around 30 multisites. In one of the multisites, I have around 200.000 posts. This is the multisite causing the timeout problems related to PHP FPM.

    When trying to edit a page on that multisite, the request takes forever until it shows a 504 Gateway Time-out error. Trying to edit a post is no issue, but trying to edit a page results in a timeout. No idea what is the difference between one or another.

    This only happens on that multisite. Multisites with less posts (one that has 40.000 posts), work as expected. So I guess the problem has to do with how database & PHP FPM work together.

    The error is the following:

    2020/05/07 17:32:26 [error] 1791#1791: *1372 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 123.123.123.123, server: website.com, request: "GET /en/wp-admin/post.php?post=90&action=edit HTTP/1.1", upstream: "fastcgi://unix:/run/php73-php-fpm-website.com.sock", host: "website.com", referrer: "https://website.com/en/wp-admin/edit.php?post_type=page"

    Any idea about where should I start looking into?

    [ Please do not bump. ]

    • This topic was modified 4 years, 10 months ago by Anonymous User 15141300.
Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator bcworkz

    (@bcworkz)

    Page edits involve an extra post meta query. I imagine that table is extremely large too.

    It seems to me your only options are to extend the time out value so there is more time allowed to complete the task; or to optimize related tables enough that queries complete faster; or to bring in more server resources so it all runs faster.

    Consider cleaning up the posts and post meta tables. Do you really need 10 different revisions of old posts available? There are likely meta data keys you don’t need as well.

    Thread Starter Anonymous User 15141300

    (@anonymized-15141300)

    wp_posts has around 215.00 entries – wp_postmeta has around 3.100.000 entries

    Can you explain in detail why “page edits” require an extra post meta query and “post edits” do not require that? Is there a way to disable that manually via functions.php?

    We have done some tests and it took 3min and 15 seconds to edit a page.
    We have already optimize DB tables in PHPMyAdmin.
    We have a dedicated server, so I don’t think server resources is a problem.

    We have done some tests in a dev environment (VPS server) and it loads correctly there, a little bit lagging, but it does not take more than 6-9 seconds to load.

    And we don’t have post revisions in our database, it is all clean.

    Is there a way we can properly debug this problem? To know exactly the root cause, if it is a memory problem, a database problem, a php problem, an nginx problem etc.

    Moderator bcworkz

    (@bcworkz)

    Pages need their template value from post meta. Posts don’t have selectable templates, so that query is not required. I really doubt that alone would make a huge difference. I don’t see how you could disable it. It’s only a contributing factor anyway. But then pages don’t normally have taxonomies. Posts do. Post meta queries are known to be inefficient. Taxonomy queries ought to be faster.

    If you’ve a mirror installation on another server that works as expected, then it’s certainly something about the server environment and not WP or the DB itself. FWIW, the WP Forums have over 12 million posts. Non-cached queries are likewise laggy on the order of several seconds, not even close to minutes. However, the forums are on a highly optimized DB that’s spread over multiple servers, so it’s not like the environment isn’t built for the size.

    Try examining server resource usage stats. It seems like something is being maxed out. phpMyAdmin has a monitor app under “status” tab you can use if you have access to the server level.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Upstream Timed Out – PHP FPM – Big WordPress Site’ is closed to new replies.