Your wordpress server appears to be overloaded.

Hi guys!

I’m getting the error below when trying to call gatsby develop.

 ERROR #gatsby-source-wordpress-experimental_111007 

 gatsby-source-wordpress  Your wordpress server at http://localwp/graphql appears to be overloaded.

Try reducing the requestConcurrency for content updates or the previewRequestConcurrency for previews:

{
  resolve: 'gatsby-source-wordpress-experimental',
  options: {
    schema: {
      requestConcurrency: 5, // currently set to 5
      previewRequestConcurrency: 2, // currently set to 2
    }
  },
}

The GATSBY_CONCURRENT_REQUEST environment variable is no longer used to control concurrency.
If you were previously using that, you'll need to use the settings above instead.

I tried to set requestConcurrency: 5 and previewRequestConcurrency: 2 as suggested but it was not enough.

Things I did before getting error appeared that may be related:

• I updated the WPGraphQL plugin (v1.1.1) today (I tried to downgrade to v1.1.0 but the problem persists)
• I set useGatsbyImage (within the ‘gatsby-source-wordpress-experimental’ options in gatsby-config.js) to false to do some tests.

Plugins used on Wordpress are: WP Gatsby (v0.9.1), WP GraphQL (v1.1.0), WP GraphQL Gutenberg (v0.3.5).

I’m running a local wordpress server (via Local) and it seems to be working normally.

Appreciate any help!

[babgyy]

Our team recently managed to have a quite stable setup with Gatsby / Wordpress / Gutenberg integration using WP Gatsby, WP GraphQL, WP GraphQL Gutenberg. Just sharing our experience if it can help

TL;DR

Excluding non desired types and fields reduced the size of a single GraphQL query made to Wordpress server from 790 Ko to 4 Ko ! This tremendously cut build times and our wordpress server never overloads.

Long story

Our Gatsby / Wordpress / Gutenberg setup was overloading the server, causing our builds to crash intermittently, and to last at least 30 minutes on a clean build.

Digging in the GraphQL schema, we realized how many custom types and attributes we were loading in the schema, even though our content writers never used the vast majority of them. Most of them were coming from Gutenberg plugins.

Using the writeQueriesToDisk parameter, we were able to see just how big were the sizes of the GraphQL queries when the WP GraphQL Gutenberg was enabled : 790 Ko for a Post or for a Category.

By excluding all the Types and all the Fields that we don’t use, we reduced the size of a single query to 4Ko Here is an extract of our config : https://gist.github.com/babgyy/cba9f6f4b5b737913739ff4d9eb034b1

Now, a clean build lasts ~10 minutes which is not much more than it was before, most of the time being spent dealing with images. And our Wordpress server stopped being overloaded.

Only downside is that our wordpress users are limited in what they can use, but that forces us to communicate and prevents unexpected results.

Cutting down the queries bit by bit : ⬇️

[vimarshacooray]

@vimarshacooray in your case it might be accurate because your local internet connection is likely much slower than the connection in your pipeline. Faster internet speed means it will try to fetch data and files more quickly which can cause your WP server to stop responding.

@TylerBarnes I just found the reason for this. it had nothing to do with my wordpress overloading or internet speed. its an 8GB 4C server with 5 posts on it with no traffic. no way its going to overload that easily. memory was limited to 128MB but increased it to 4GB on WP. i have dropped it down to 128MB after finding the issue.

-> Cloudflare was blocking the request on the pipeline (bot defend mode). ⚰️😅 but it allowed the connection when running locally.

Hope this info helps someone!