运行gatsby develop时WordPress过载，调整并发配置问题仍未解决

调低并发参数到适配本地环境的阈值 #

• 报错提示给出的参考并发值是面向生产环境的，Local搭建的本地WordPress默认资源配置很低，直接套用参考值很容易打满进程。把gatsby-config.js里的参数调整为：

  {
    resolve: 'gatsby-source-wordpress-experimental',
    options: {
      schema: {
        requestConcurrency: 2,
        previewRequestConcurrency: 1
      }
    }
  }
  

• 不要尝试用GATSBY_CONCURRENT_REQUEST环境变量控制并发，当前版本的插件已经完全不读取这个变量的配置，设置了也不生效。

逐一对冲突插件做禁用验证 #

• 临时关掉WP GraphQL Gutenberg v0.3.5：这个版本和WPGraphQL v1.1.x搭配时存在查询阻塞问题，会让GraphQL端点超时无响应，直接被Gatsby的源插件判定为服务器过载。关掉之后再跑命令验证。
• 临时关掉WP Gatsby v0.9.1：这个版本存在重复轮询请求的bug，会偷偷占满所有WordPress的PHP进程，就算单看WordPress后台显示运行正常，也会导致GraphQL端点接不到Gatsby的请求。

验证之前修改的配置是否是诱因 #

• 把之前为了测试设置的useGatsbyImage: false临时改回默认值true重新跑命令：关掉Gatsby Image支持后，插件会把所有媒体附件的字段拆成独立的请求发出去，总请求量会比开启时高3-4倍，哪怕并发数设得低，总请求数堆起来也会触发过载判定。
• 如果改回之后报错消失，后续需要用关闭Gatsby Image的配置时，要把requestConcurrency再压到1，才能匹配对应的请求量级。

调整Local站点的运行资源配置 #

• 打开Local工具的站点设置，把当前站点的PHP运行内存从默认256M调到512M，把PHP最大执行时间从默认30秒调到120秒，重启站点后再执行gatsby develop。
• 直接在浏览器打开http://localwp/graphql，手动发一个最简查询{ posts { nodes { id } } }，看响应速度：如果响应要等好几秒，说明过载是WordPress端本身查询太慢导致的，和Gatsby侧的并发设置没关系。

清理两侧的残留缓存 #

• 删掉Gatsby项目下的.cache、node_modules/.cache目录，清除之前异常运行留下的重复请求逻辑缓存。
• 进入WordPress后台的WPGraphQL设置页，点清除内置缓存的按钮，避免之前残留的脏查询占满进程。

内容的提问来源于stack exchange，提问作者alexandre_anicio