複製レポをご用意いただけますか？ 投稿の数は問題にならないはずです（少なくともこのステップでは）-v1はメモリの問題に陥る可能性がありますが、これは後のビルドステップにあり、スタックしないはずです

それはとの問題だった場合は興味があったフライホイールによる局所、及び経てワードプレスを提供する際に、サイトを構築することができMAMP Proを。

しかし、私はまだ投稿ページを作成していません（ページを作成しています）。その問題のあるステップの実行時間は636.41秒です（11分は恥ずかしがり屋です）。

const path = require('path')

exports.createPages = ({ boundActionCreators, graphql }) => {
  const { createPage } = boundActionCreators

  const postTemplate = path.resolve('./src/templates/Post/Post.js')

  graphql(
    `
      {
        allWordpressPost {
          edges {
            node {
              id
              slug
            }
          }
        }
      }
    `
  )
    .then((result) => {
      console.log('posts')
      // const { data, errors } = result

      // if (errors) console.log(errors)

      // if (!data) return

      //data.allWordpressPost.edges.forEach(({ node }) => {
      //  const { id, slug } = node

      //  createPage({
      //    component: postTemplate,
      //    context: {
      //      id,
      //    },
      //    path: slug,
      //  })
      //})
    })

編集：投稿に対してcreatePageを有効にするだけで、そのアイテムの実行は14分になりました。 残忍ですが、アイテムが9000個増えると、わずか3分長くなることも興味深いです。 それは現在長い間⠁ run graphql queriesに座っています。

編集：それは419.470秒、または7分間実行されました。

@piehおっと、あなたがちょうど答えたのを見る前にそれを投稿しました。 明日、このサイトをリモートで立ち上げることができます。

そして、含めることを意図して、この最後の行は、ローカルを介してハングし、MAMPを介して永遠にかかる場所です。

$ gatsby develop
success delete html and css files from previous builds — 0.017 s
success open and validate gatsby-config — 0.226 s
info One or more of your plugins have changed since the last time you ran Gatsby. As
a precaution, we're deleting your site's cache to ensure there's not any stale
data
success copy gatsby files — 0.013 s
success onPreBootstrap — 0.159 s
⠁ source and transform nodes -> wordpress__acf_posts fetched : 100
⠁ source and transform nodes -> wordpress__acf_pages fetched : 34
⠂ source and transform nodes -> wordpress__acf_media fetched : 100
⠈ source and transform nodes -> wordpress__acf_categories fetched : 13
⢀ source and transform nodes -> wordpress__acf_tags fetched : 0
⠄ source and transform nodes -> wordpress__acf_users fetched : 11
⢀ source and transform nodes -> wordpress__POST fetched : 9092
⢀ source and transform nodes -> wordpress__PAGE fetched : 34
⠐ source and transform nodes -> wordpress__wp_media fetched : 7483
⡀ source and transform nodes -> wordpress__wp_types fetched : 1
⠁ source and transform nodes -> wordpress__wp_statuses fetched : 1
⢀ source and transform nodes -> wordpress__wp_taxonomies fetched : 1
⠄ source and transform nodes -> wordpress__CATEGORY fetched : 14
⠈ source and transform nodes -> wordpress__TAG fetched : 19
⠐ source and transform nodes -> wordpress__wp_users fetched : 11
⡀ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "You are not currently logged in."
⠈ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
⡀ source and transform nodesThe server response was "404 Not Found"
Inner exception message : "No route was found matching the URL and request method"
success source and transform nodes — 636.410 s

@piehこれが正常にビルドされることを確認していません（現在、WordPressリモートでは、数時間かかります）が、確かに問題が明らかになります： //github.com/dustinhorton/gatsby-issue

それを複製してビルドできるはずです。

サイトの構築が完了せずに、10時間以上2回実行しただけです。 デバッグを支援するために他に何を提供できるか教えてください。

v2にアップグレードしてみてください。 さまざまなgatsbyサブシステムの速度を大幅に改善しました。これにより、このような大規模なサイトの速度が劇的に向上するはずです。

@KyleAMathews今夜そのショットをあげます—ありがとう。

@ KyleAMathewsv2バージョン：//github.com/dustinhorton/gatsby-v2-issue。 この時点で約50分間構築されています。

今それを殺します。 サイトはまだ構築されていません。

試すことができるもう1つのことは、トレースを有効にすることですhttps://next.gatsbyjs.org/docs/performance-tracing/

gatsby-source-wordpressにはまだトレースのサポートが追加されていませんが、トレースレポートは、停止している場所を特定するのに役立つ場合があります。

他の誰かがこれを調べることに興味があるなら、素晴らしいPRはgatsby-source-wordpressにトレースサポートを追加することです。 Lemmeはあなたが興味を持っているかどうか知っています！

残念ながら、これを回避する必要があります。これは、Gatsbyを使用できないように押しつぶされたような、従来のテーマに移植するためにすべての時間を費やす必要があるためです。 他のすべてはとても後ろ向きに感じます。

申し訳ありませんが、これを調べる機会がありませんでした:-( v2をリリースするために今スプリントしています。

WPサイトを実行したままにしておく可能性はありますか？ ここには修正が必要なバグがあるようです。

私は助けを求めてツイートしたので、誰かがすぐにこれに飛びつくことを願っています:-)

https://twitter.com/gatsbyjs/status/1027079401287102465

うわー、それはすごいです—どうもありがとう。 当面、サイトはどこにも行きません（必要に応じて、コピーを移行して再現リポジトリを更新します）。

@dustinhortonは、その前にCDNがある本番環境と比較して、Local by Flywheelでより大きな（〜1,000ポスト）プロジェクトを構築する際の問題にも気づきました。

GatsbyのREST応答は、本番環境よりもローカル環境の方が10〜20倍長いため、サイトの構築には永遠に時間がかかります。 Localでの問題のデバッグにはまだ時間を費やしていませんが、やることリストに載っています:)

@ KyleAMathewssource -wordpressにトレースを追加する方法を見てみましょう。

@Khristophorそれは素晴らしいでしょう！

@dustinhortonサンプルサイト（https://dustinhorton.com/gatsby-wp/wp-content/uploads/2018/07/IMG_9906.jpgなど）の画像で404が表示され、ビルドが膨らんでいる可能性があります時間。 それらの道を調べるチャンスはありますか？

WP_MEDIAリクエストはかなり速く実行され、結果が出たので、
明確ですが、あなたがそれを考えるならば、私は今週後半にそれを見ることができます
場合があります。

17:45クリス・ワイズマンの水曜日、2018年8月8日には[email protected]
書きました：

@dustinhortonhttps ：//github.com/dustinhorton私は404のを見てい
サンプルサイトの画像（
https://dustinhorton.com/gatsby-wp/wp-content/uploads/2018/07/IMG_9906.jpg、
たとえば）ビルド時間が長くなる可能性があります。 あなたができるあらゆるチャンス
それらの道を調べますか？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment-411562589 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAXFNRHTA-vqIwCTtioejUL-Ei3nM0Lbks5uO1vygaJpZM4VZ57n
。

それは本当ですが、ソースと変換のステップの一部は、REST応答で見つかったすべてのメディアアイテムをダウンロードすることです。
https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-wordpress/src/normalize.js#L434

7504の画像で404を取得すると、いくつかの問題が発生する可能性があります;）

私はすべての404をクリーンアップしたと信じています。 今夜ビルドしようとします。 皆さんありがとう。

一見変化なし：

~/Sites/gatsby-issue-v2 (master)
→yarn build
yarn run v1.5.1
$ gatsby build
success open and validate gatsby-config — 0.009 s
success load plugins — 0.277 s
success onPreInit — 0.257 s
success delete html and css files from previous builds — 0.008 s
success initialize cache — 0.245 s
success copy gatsby files — 0.079 s
success onPreBootstrap — 0.001 s
⠁
=START PLUGIN=====================================

Site URL: http://dustinhorton.com/gatsby-wp
Site hosted on Wordpress.com: false
Using ACF: true
Using Auth: undefined undefined
Verbose output: true

Mama Route URL: http://dustinhorton.com/gatsby-wp/wp-json

⠁ source and transform nodesRoute discovered : /
Invalid route.
Route discovered : /oembed/1.0
Invalid route.
Route discovered : /oembed/1.0/embed
Invalid route.
Route discovered : /oembed/1.0/proxy
Invalid route.
Route discovered : /yoast/v1
Valid route found. Will try to fetch.
Route discovered : /yoast/v1/configurator
Valid route found. Will try to fetch.
Route discovered : /yoast/v1/reindex_posts
Valid route found. Will try to fetch.
Route discovered : /yoast/v1/ryte
Valid route found. Will try to fetch.
Route discovered : /yoast/v1/indexables/(?P<object_type>.*)/(?P<object_id>\d+)
Invalid route.
Route discovered : /yoast/v1/statistics
Valid route found. Will try to fetch.
Route discovered : /acf/v3
Invalid route.
Route discovered : /acf/v3/posts/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/posts
Valid route found. Will try to fetch.
Route discovered : /acf/v3/pages/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/pages
Valid route found. Will try to fetch.
Route discovered : /acf/v3/media/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/media
Valid route found. Will try to fetch.
Route discovered : /acf/v3/categories/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/categories
Valid route found. Will try to fetch.
Route discovered : /acf/v3/tags/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/tags
Valid route found. Will try to fetch.
Route discovered : /acf/v3/comments/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/comments
Valid route found. Will try to fetch.
Route discovered : /acf/v3/options/(?P<id>[\w\-\_]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/users/(?P<id>[\d]+)/?(?P<field>[\w\-\_]+)?
Invalid route.
Route discovered : /acf/v3/users
Valid route found. Will try to fetch.
Route discovered : /wp/v2
Invalid route.
Route discovered : /wp/v2/posts
Valid route found. Will try to fetch.
Route discovered : /wp/v2/posts/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/posts/(?P<parent>[\d]+)/revisions
Invalid route.
Route discovered : /wp/v2/posts/(?P<parent>[\d]+)/revisions/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/pages
Valid route found. Will try to fetch.
Route discovered : /wp/v2/pages/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/pages/(?P<parent>[\d]+)/revisions
Invalid route.
Route discovered : /wp/v2/pages/(?P<parent>[\d]+)/revisions/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/media
Valid route found. Will try to fetch.
Route discovered : /wp/v2/media/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/types
Valid route found. Will try to fetch.
Route discovered : /wp/v2/types/(?P<type>[\w-]+)
Invalid route.
Route discovered : /wp/v2/statuses
Valid route found. Will try to fetch.
Route discovered : /wp/v2/statuses/(?P<status>[\w-]+)
Invalid route.
Route discovered : /wp/v2/taxonomies
Valid route found. Will try to fetch.
Route discovered : /wp/v2/taxonomies/(?P<taxonomy>[\w-]+)
Invalid route.
Route discovered : /wp/v2/categories
Valid route found. Will try to fetch.
Route discovered : /wp/v2/categories/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/tags
Valid route found. Will try to fetch.
Route discovered : /wp/v2/tags/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/users
Valid route found. Will try to fetch.
Route discovered : /wp/v2/users/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/users/me
Valid route found. Will try to fetch.
Route discovered : /wp/v2/comments
Valid route found. Will try to fetch.
Route discovered : /wp/v2/comments/(?P<id>[\d]+)
Invalid route.
Route discovered : /wp/v2/settings
Valid route found. Will try to fetch.
Added ACF Options route.

Fetching the JSON data from 25 valid API Routes...

=== [ Fetching wordpress__yoast_v1 ] === https://dustinhorton.com/gatsby-wp/wp-json/yoast/v1
⠈ source and transform nodes -> wordpress__yoast_v1 fetched : 1
Fetching the wordpress__yoast_v1 took: 936.166ms

=== [ Fetching wordpress__yoast_configurator ] === https://dustinhorton.com/gatsby-wp/wp-json/yoast/v1/configurator
⢀ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
Fetching the wordpress__yoast_configurator took: 846.014ms

=== [ Fetching wordpress__yoast_reindex_posts ] === https://dustinhorton.com/gatsby-wp/wp-json/yoast/v1/reindex_posts
⢀ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
Fetching the wordpress__yoast_reindex_posts took: 1010.589ms

=== [ Fetching wordpress__yoast_ryte ] === https://dustinhorton.com/gatsby-wp/wp-json/yoast/v1/ryte
⠠ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
Fetching the wordpress__yoast_ryte took: 1022.977ms

=== [ Fetching wordpress__yoast_statistics ] === https://dustinhorton.com/gatsby-wp/wp-json/yoast/v1/statistics
⠄ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
Fetching the wordpress__yoast_statistics took: 820.827ms

=== [ Fetching wordpress__acf_posts ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/posts
⠈ source and transform nodes -> wordpress__acf_posts fetched : 100
Fetching the wordpress__acf_posts took: 6352.670ms

=== [ Fetching wordpress__acf_pages ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/pages
⡀ source and transform nodes -> wordpress__acf_pages fetched : 34
Fetching the wordpress__acf_pages took: 2760.048ms

=== [ Fetching wordpress__acf_media ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/media
⠈ source and transform nodes -> wordpress__acf_media fetched : 100
Fetching the wordpress__acf_media took: 4273.250ms

=== [ Fetching wordpress__acf_categories ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/categories
⠁ source and transform nodes -> wordpress__acf_categories fetched : 13
Fetching the wordpress__acf_categories took: 1029.029ms

=== [ Fetching wordpress__acf_tags ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/tags
⠈ source and transform nodes -> wordpress__acf_tags fetched : 0
Fetching the wordpress__acf_tags took: 941.066ms

=== [ Fetching wordpress__acf_comments ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/comments
⢀ source and transform nodes -> wordpress__acf_comments fetched : 9
Fetching the wordpress__acf_comments took: 2868.036ms

=== [ Fetching wordpress__acf_users ] === https://dustinhorton.com/gatsby-wp/wp-json/acf/v3/users
⠠ source and transform nodes -> wordpress__acf_users fetched : 11
Fetching the wordpress__acf_users took: 2049.181ms

=== [ Fetching wordpress__POST ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/posts
⠁ source and transform nodes
Total entities : 9094
Pages to be requested : 91
⠁ source and transform nodes -> wordpress__POST fetched : 9094
Fetching the wordpress__POST took: 152767.807ms

=== [ Fetching wordpress__PAGE ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/pages
⢀ source and transform nodes -> wordpress__PAGE fetched : 34
Fetching the wordpress__PAGE took: 2194.895ms

=== [ Fetching wordpress__wp_media ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media
⢀ source and transform nodes
Total entities : 7504
Pages to be requested : 76
⢀ source and transform nodes -> wordpress__wp_media fetched : 7485
Fetching the wordpress__wp_media took: 132029.996ms

=== [ Fetching wordpress__wp_types ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/types
⢀ source and transform nodes -> wordpress__wp_types fetched : 1
Fetching the wordpress__wp_types took: 956.603ms

=== [ Fetching wordpress__wp_statuses ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/statuses
⢀ source and transform nodes -> wordpress__wp_statuses fetched : 1
Fetching the wordpress__wp_statuses took: 1017.845ms

=== [ Fetching wordpress__wp_taxonomies ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/taxonomies
⠠ source and transform nodes -> wordpress__wp_taxonomies fetched : 1
Fetching the wordpress__wp_taxonomies took: 1029.885ms

=== [ Fetching wordpress__CATEGORY ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/categories
⢀ source and transform nodes -> wordpress__CATEGORY fetched : 14
Fetching the wordpress__CATEGORY took: 943.710ms

=== [ Fetching wordpress__TAG ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/tags
⠠ source and transform nodes -> wordpress__TAG fetched : 19
Fetching the wordpress__TAG took: 1104.454ms

=== [ Fetching wordpress__wp_users ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/users
⡀ source and transform nodes -> wordpress__wp_users fetched : 11
Fetching the wordpress__wp_users took: 1325.604ms

=== [ Fetching wordpress__wp_me ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/users/me
⠂ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "You are not currently logged in."
Fetching the wordpress__wp_me took: 926.146ms

=== [ Fetching wordpress__wp_comments ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/comments
⠂ source and transform nodes
Total entities : 9410
Pages to be requested : 95
⡀ source and transform nodes -> wordpress__wp_comments fetched : 9397
Fetching the wordpress__wp_comments took: 85370.673ms

=== [ Fetching wordpress__wp_settings ] === https://dustinhorton.com/gatsby-wp/wp-json/wp/v2/settings
⠁ source and transform nodesThe server response was "401 Unauthorized"
Inner exception message : "Sorry, you are not allowed to do that."
Fetching the wordpress__wp_settings took: 808.396ms

=== [ Fetching wordpress__acf_options ] === http://dustinhorton.com/gatsby-wp/wp-json/acf/v2/options
⠂ source and transform nodesThe server response was "404 Not Found"
Inner exception message : "No route was found matching the URL and request method"
Fetching the wordpress__acf_options took: 1059.276ms

=END PLUGIN=====================================: 412457.896ms
⠁ source and transform nodes

そしてそれは約8時間そこに座っています。

@dustinhortonどのようなホスティングを使用していますか？ リクエストの量であなたのプロダクションボックスを殺しているだけだと思います。 同時接続を1または2などの低い値に設定して（8時間ではなく、かなりの時間が経過した後）終了したと思います。

LinodeではまともなVPSです。 それが助けになるなら、私はそれに設定を微調整することができます。 しかし、問題はローカルでも発生します。

https://github.com/gatsbyjs/gatsby/blob/46290c2b0e7894fca036bdcc658a5d1936c4221f/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L133 -L159大量にプルすると、これが正しく機能しない場合がありresponseStreamを待つように仕上げfsWriteStreamおそらく（仕上げにし、そうでない場合は、すべてのリソースを破棄して、再度書き込みファイルにしてみてください数回の再試行を行います）、実際にそれができない場合は実際にエラーになります。

@piehこのファイルの更新されたコードを送って

/packages/gatsby-source-filesystem/src/create-remote-file-node.js

@ aman-developerこれに対する修正はまだありません-そうでなければ、公開されます。 この問題の問題は、これを再現する信頼できる方法がないことです。したがって、修正は推測です。 問題は場合によっては（ハードウェアおよび/またはOS固有の可能性があります）ファイルシステムwriteStreamが終了せず、エラーをスローせずにスタックしているため、ここでの修正は実際にfsパッケージ/ハードウェア/ OSの問題を回避しようとしています信頼できない：/

私のリポジトリとサイトで再現するのに問題がありましたか？ それは私にとって一貫しています。

createRemoteFileNodeを使用してリモートイメージをフェッチしましたが、これと同じ問題が発生します。ダウンロードが680 / 780ish前後でスタックします。

createRemoteFileNodeには、 https：//github.com/sindresorhus/got/releases/tag/v8.0.0で追加されたdownloadProgressイベントのリスナーがありますが、gatsby-source-filesystemは7.1.0を使用しています。

最新バージョン9.2.2にアップグレードしてみたところ、すべてのイメージを正常にダウンロードできるようになりました。

これをpackage.jsonに追加します。

  "resolutions": {
    "got": "^9.2.2"
  }

また、ストリームエラーが正しく転送されないなど、7.1.0以降のgetにはいくつかの重要な修正があるようです（https://github.com/sindresorhus/got/releases/tag/v8.0.1）

got更新しようとしましたが、それでもスタックすることがありますが、とにかくそれを行う価値があります。 downloadProgressものは、無効にするか、より良い出力が必要になることに注意してください。これは、ターミナル/コンソールを使用すると、進行状況がスパムされるためです。

約25分後にgatsby developを実行できましたが、create-remote-file-node.jsの同時実行数を200から20に減らす必要がありました。22個のTimeoutErrorsが発生しました（ただし、gatsbydevelopの実行時に再ダウンロードされました）再び）processRemoteNodeの空のキャッチにログを入れた後。

取得したためかどうかはわかりませんが、他のhttpクライアントで実験できる可能性があります...

...
success source and transform nodes — 1407.531 s
success building schema — 3.315 s
success createPages — 0.571 s
success createPagesStatefully — 2.797 s
success onPreExtractQueries — 0.012 s
success update schema — 3.268 s
warning There are conflicting field types in your data. GraphQL schema will omit those fields.
wordpress__wp_media.media_details.width:
 - type: number
   value: 916
 - type: string
   value: '224'
wordpress__wp_media.media_details.height:
 - type: number
   value: 916
 - type: string
   value: '225'
wordpress__wp_media.media_details.sizes.thumbnail.width:
 - type: number
   value: 150
 - type: string
   value: '150'
wordpress__wp_media.media_details.sizes.thumbnail.height:
 - type: number
   value: 150
 - type: string
   value: '150'
wordpress__wp_media.media_details.sizes.medium.width:
 - type: number
   value: 300
 - type: string
   value: '300'
wordpress__wp_media.media_details.sizes.medium.height:
 - type: number
   value: 300
 - type: string
   value: '200'
wordpress__wp_media.media_details.sizes.large.width:
 - type: number
   value: 768
 - type: string
   value: '1024'
wordpress__wp_media.media_details.sizes.large.height:
 - type: number
   value: 1024
 - type: string
   value: '682'
wordpress__wp_media.media_details.image_meta.aperture:
 - type: number
   value: 2.2
 - type: string
   value: '0'
wordpress__wp_media.media_details.image_meta.created_timestamp:
 - type: boolean
   value: false
 - type: number
   value: 1433226914
 - type: string
   value: '0'
wordpress__wp_media.media_details.image_meta.focal_length:
 - type: number
   value: 0
 - type: string
   value: '0'
wordpress__wp_media.media_details.image_meta.iso:
 - type: number
   value: 0
 - type: string
   value: '0'
wordpress__wp_media.media_details.image_meta.shutter_speed:
 - type: number
   value: 0
 - type: string
   value: '0'
wordpress__wp_media.media_details.image_meta.orientation:
 - type: number
   value: 1
 - type: string
   value: '1'
warning Using the global `graphql` tag is deprecated, and will not be supported in v3.
Import it instead like:  import { graphql } from 'gatsby' in file:
/Users/tandingan.wlb/Projects/gatsby/gatsby-issue/src/templates/Post/Post.js
success extract queries from components — 0.120 s
success run graphql queries — 223.335 s — 9121/9121 40.84 queries/second
success write out page data — 0.119 s
success write out redirect data — 0.001 s
success onPostBootstrap — 0.027 s

info bootstrap finished - 1643.854 s

{ TimeoutError: Timeout awaiting 'request' for 30000ms
    at Immediate.timeoutHandler [as _onImmediate] (/Users/tandingan.wlb/Projects/gatsby/gatsby-issue/node_modules/got/source/timed-out.js:39:25)
    at runCallback (timers.js:694:11)
    at tryOnImmediate (timers.js:664:5)
    at processImmediate (timers.js:646:5)
  name: 'TimeoutError',
  code: 'ETIMEDOUT',
  host: 'dustinhorton.com',
  hostname: 'dustinhorton.com',
  method: 'GET',
  path: '/gatsby-wp/wp-content/uploads/2015/05/20150302_061259.jpg',
  socketPath: undefined,
  protocol: 'https:',
  url:
   'https://dustinhorton.com/gatsby-wp/wp-content/uploads/2015/05/20150302_061259.jpg',
  event: 'request' }

プリズムでも同じエラーが発生します

「got」にアップグレードしました：「^ 9.2.2」が動作しています！

gotバージョンをアップグレードするには、ぜひご覧ください。 これは断続的な問題であるため、それが機能したのは偶然の一致かもしれません。 @RobinHerzogアップグレードされたバージョンのgot同様の問題が発生する場合は、お知らせください。

got更新すると、レプロリポジトリのビルド時間が大幅に短縮されましたが、最後に試したときは一貫して1時間近くかかりました。

@dustinhortonビルドのどの部分がイメージをプルしていましたか（または、ファイルのダウンロードにかかる時間を明示的に示していないため、 source and transform data ）？

1GBのインターネット接続で150MBの画像があります。 今は動作しています。ダウンロードしてビルドを続行するには30秒かかります。

私も一貫してこの問題を抱えています。 gotアップグレードしても、これは解決しませんでした。 source-wordpressにトレースを追加して、問題が何であるかをデバッグできるようにすることに成功しましたか？

concurrentRequestsとperPage 、 gotを最新バージョンにアップグレードしようとしましたが、どれも機能しませんでした。 現在、 categories 、 posts 、 pages 、 tagsをフェッチできますが、 usersまたはmediaを含めると、 =END PLUGIN===直後に、プラグインはエラーTypeError: Cannot read property 'id' of undefined戻ります。

すべてのルートを含めて、アクセスできないルートをブラックリストに登録すると、 =END PLUGIN===が表示されますが、終了しません...これは、テストした多数のWebサイトに当てはまるので、どういうわけか私のシステムである可能性があります。 。 誰かがこれをテストしたい場合は、ここに設定があります：

    {
      resolve: 'gatsby-source-wordpress',
      options: {
        // Other URLs I tried:
        // https://clubedovalor.com.br
        // http://rivainvestimentos.com.br
        // http://queroinvestiragora.com/
        // https://www.clubedospoupadores.com/
        baseUrl: "aprenda.guiainvest.com.br",
        protocol: "https",
        hostingWPCOM: false,
        useACF: false,
        concurrentRequests: 10,
        perPage: 50,
        // Going with the excluded routes path
        // excludedRoutes: [
        //   '/*/*/plugins',
        //   '/rock-convert/**',
        //   '/yoast/**',
        //   '/wp-super-cache/**',
        //   '/*/*/users/me',
        //   '/*/*/settings',
        // ],
        verboseOutput: true,
        includedRoutes: [
          "/*/*/categories",
          "/*/*/posts",
          "/*/*/pages",
          "/*/*/tags",
          // You can toggle between media and users (or both)
          // All 3 scenarios will fail with the `'id' of undefined`
          // problem
          // "/*/*/media",
          "/*/*/users",
        ],
      },

PS：私がなんとか取得したURLの1つはhttps://wesbos.com/

ハッピーアップデート：クエリにtaxonomiesを含めることで、 usersやmediaでも、 includedRoutesで（_小規模なサイトの場合は_）動作させることができました。 。 今、私は'id' of undefinedエラーを受け取りません：D

@pieh usersとmediaタイプはtaxonomiesに依存していると思います。したがって、構成にこれらのタイプのいずれかが含まれている場合は、デフォルトでこれらのタイプを使用する必要がありますか？ さらにトラブルシューティングをお手伝いできるかどうか教えてください！ 最後に、このtaxonomiesバグは、無限のビルドプロセスとは無関係のようです。 最大500のメディアファイルを超えるサイトでは、まだビルドプロセスを完了できません。

更新番号2 ：それで、私はqueroinvestiragora.comで動作させることができました。これには、600のメディアファイルがありますが、投稿は70しかありません。 =END PLUGIN===から約15秒かかりますが、動作します。 ただし、 www.clubedospoupadores.comは702個のメディアファイルと336個の投稿があり、コンパイルされません。

PS：これらの実験での私の設定は次のとおりです。

    {
      resolve: 'gatsby-source-wordpress',
      options: {
        baseUrl: "queroinvestiragora.com",
        protocol: "http",
        hostingWPCOM: false,
        useACF: false,
        concurrentRequests: 10, // I've also tried removing it and going with the default, it's the same result
        verboseOutput: true,
        includedRoutes: [
          "/*/*/categories",
          "/*/*/posts",
          "/*/*/pages",
          "/*/*/tags",
          "/*/*/media",
          "/*/*/users",
          "/*/*/taxonomies",
        ],
      },
    },

こんにちは、

ここで概説されている手順https://www.gatsbyjs.org/docs/performance-tracing/を使用して、トレースを追加することができました。 残念ながら、ソースノードとトランスフォームノードにはかなり時間がかかっていると単純に教えてくれたため、多くの情報は提供されませんでした。

ただし、画像に関連する非決定論的な動作を行った後、この問題について独自のデバッグをいくつか行いました。 開発スクリプトまたはビルドスクリプトのいずれかを実行すると、すべてのイメージがダウンロードされず、localFileノードが完了しない場合があります。 コードを掘り下げた後、ここに問題があるようだと判断しました

https://github.com/gatsbyjs/gatsby/blob/ad142af473fc8dc8555a5cf23a0dfca42fcbbe90/packages/gatsby-source-wordpress/src/normalize.js#L483 -L506

私の場合、サーバーのタイムアウトエラーが原因でcreateRemoteFileノードが失敗し、デフォルトでnullが返されていました。 これを判別して実際のサーバー応答を取得するには、createRemoteFileノードにもログを追加する必要がありました。 これらのノードは完了せず、IDを持たないため、キャッシュに登録されません。 tmpファイルが削除され、gatsby-source-filesystemが不完全でした。 何らかの理由で（私はまだそれほど詳しくは調べていませんが）、ビルドスクリプトを再度実行すると、おそらくスクリプトがファイルシステムが無効または不完全であることを検出したために、ソースファイルシステムが削除されました。 このプロセスが私にとってループを作成し、ファイルシステムが完了しないために将来のビルドでエラーを引き起こしました。

私は、少なくとも大量の画像に関する問題のいくつかを軽減するように見える修正に取り組んでいます。 開発またはビルドスクリプトが最初にすべてのイメージのダウンロードに成功した場合、その後は削除されず、イメージがgatsby-source-filesystemによって適切にキャッシュされるため、ビルドプロセスが非常に迅速に実行されます。 私のビルドは15分から1分に短縮されました。

これが大量の投稿があるビルドに関連しているかどうかはわかりません。 私の問題は、1.6GBの画像データのダウンロードに直接関係していました。

gatsbyのソースプラグインを使用するのはこれが初めてなので、誰かがこれについて何か考えやアドバイスがあれば、私はそれをいただければ幸いです！ 今日の後半にリポジトリを投稿できるようになるはずです。ローカルバージョンのgatsby-source-filesystemを問題なく使用できるように取り組んでいます。

こんにちは、

数日前の私のコメントのフォローアップ。 これが私のリポジトリです。

https://github.com/njmyers/byalejandradesign.com.git

このプロジェクトではmonorepoを使用しているので、リポジトリをローカルで実行する場合の手順を次に示します。

1. Yarn1.12.3の最新バージョンを使用していることを確認してください
2. プラグインブランチのクローンを作成しますgit clone https://github.com/njmyers/byalejandradesign.com.git -b wordpress-plugin
3. yarn && yarn bootstrap実行します
4. gatsbyフォルダーに移動して、そのフォルダーだけを見ることができるようにしますcd packages/web
5. yarn developまたはyarn build-webます。 初回は正常に完了するはずであり、その後同じコマンドを実行すると、ビルドがはるかに高速になります。 ソースノードとトランスフォームノードは222秒かかりますが、以前の3倍かかっていた、または完了していませんでした。
6. ソースと変換中に実際に何が起こっているかを確認したい場合は、ファイルブラウザで/packages/web/.cache/gatsby-source-filesystemを確認すると、ファイルがそこで作成されていることがわかります。

downloadMediaFiles関数を完全に書き直しました。 このリンクでそのファイルを見ることができますhttps://github.com/njmyers/byalejandradesign.com/blob/wordpress-plugin/packages/gatsby-source-wordpress/src/download-media-files.js

おそらく必要以上に冗長ですが、起こっていることすべてを理解するためにこれを行わなければなりませんでした。 私が変更した機能は、createRemoteFileNodeがnullを返したときにpromise拒否を追加することです。 次に、関数downloadRunnerを使用してリクエストを調整し、すべてのリクエストが一度にサーバーにヒットしないようにします。また、Promiseの拒否を再試行します。 各createRemoteFileNodeリクエストの間に200msのスロットルを追加しました。 この値は微調整できると確信しており、createRemoteFileNodeに直接追加するのに適している可能性があります。

興味がある場合は、WPインストールはEC2マイクロインスタンスですが、イメージはCloudFrontディストリビューションの背後にあります。 個人的には、投稿の取得に問題はありませんでした。画像の取得に問題があり、人々が抱えている問題のほとんどはこれが原因であると考えています。

また、誰かが自分のサイトをトレースまたはデバッグしたい場合は、ここから始めることをお勧めします...

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L240 -L244

catch句にログを追加し、タイムアウトエラーが発生してnullを返したため、イメージノードが正しく処理されていないと判断できました。

@njmyers私はそれを非常に簡単に調べましたが、これが機能する場合は、 createRemoteFileNode同様のアプローチを直接使用する必要があると考えています。 そこではqueueを使用しているので、この関数（この場合はgatsby-source-wordpress ）の利用者はこれについて心配する必要はありません。 潜在的に問題となることの1つは、200ミリ秒のスロットルです。おそらくそれなしで開始でき、問題が発生し始めると、スロットルが自動的に適用されます（ホスト名ごと）。

@piehはい、おそらくこのロジックを適用する場所です。 私にとってのスロットルは、これにアプローチして問題を診断する方法だったので、 createRemoteFileNodeがそれ自体でこれを処理できるはずであることに同意します。

ただし、特に問題となるのは、エラーを黙って失敗させてnullを返すという現在の動作です。 私の意見では、操作の失敗または成功のいずれかについて何らかのコミュニケーションがあるはずです。 createRemoteFileNodeは、次の機能でより堅牢にできると思います。

1）熱心に接続を作成する
2）サーバーからのエラーがある場合は、必要に応じてスロットルおよび/または再試行を開始します
3）スロットル/再試行のためのいくつかの正しいデフォルトを設定します
4）スロットル/再試行を調整するためのエントリポイントを作成します
4）何らかの理由でノードを処理できない場合は、promiseを拒否します。

ここでタイムアウト値を試してみたとも言えますhttps://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L135- L141。 これにより、応答が成功する可能性が高まりましたが、応答を確実に成功させるには、処理を追加

ほとんどの場合、このロジックの正しいエントリポイントはここにあります。

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L259 -L269

タスクが失敗した場合、それらは再試行および/または失敗し、最終的に拒否されます。

また、 queueドキュメントを簡単に読んでください。 queueがそれ自体でこれを管理できることについてあなたが言っていることがわかります。

@njmyers素敵な調査作業！ ファイルのダウンロードはもっと賢くする必要があることに間違いなく同意します！

リモートファイルのダウンロードとキャッシュのこの問題に焦点を当てた独自のパッケージにファイルダウンロードピースを抽出することは、実際には素晴らしいことかもしれません。

ギャツビーと将来の複数の場所でこの機能を使用する必要がある可能性は十分にあります。これは、インターネット上の他の人々も同様に使用したいと思うものです。

@KyleAMathewsは、 createRemoteFileNodeを別のパッケージに抽出することを意味しますか？

ファイルのダウンロードとキャッシュの部分だけではありません。 createRemoteFileNodeは、このパッケージを呼び出すだけで、ファイルがダウンロードされたとき（またはキャッシュから返されたとき）に解決されるpromiseを返します。

自分のコックピットソースプラグインでもこの問題が発生しています。

なるほど、コードのこれらの部分を別のパッケージに抽出するようなものになるでしょう...

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L125 -L244

これは特にダウンロードとキャッシュを扱うコードのようです。間違っている場合は訂正してください。 これに取り組んで幸せです！ それがより大きな生態系でどのように機能するかを理解しようとしているだけです。

gatsby-source-wordpressのみを修正するPRは受け入れられ、後で修正を抽出しますか？ @njmyersフォークプラグインを

@dustinhortonは、これが役立つかどうかは

https://github.com/njmyers/byalejandradesign.com/blob/d56b1938f6d1bc22c3cf2282bb3198e378fe3561/packages/web/gatsby-config.js#L91 -L94

この問題と、説明した新しいプラグインでさえ、私はまだ満足しています。 これを統合する方法について少しガイダンスを探しているだけです。これは、私が気付いていない他の多くのことに影響を与える可能性のある破壊的な変更のように思われるためです。 @KyleAMathews何か考えはありますか？ 私はまだここのコードのように感じます

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L125 -L244

独自のパッケージに抽出する必要がある部分です。 そうは言っても、それはcreateRemoteFileNodeのコア機能の1つであり、エコシステムに適切に統合できるように、正しく実行することを確認したいと思います。

@njmyersコードの選択はほぼ正しいです。現在のキュー（ATMは200の同時リクエストに制限されていますが、ローカル開発者にとっては良くなく、WordPressにとっては明らかにそうではないようです）も移動し、おそらく変更する必要があります。

@dustinhorton最初にwordpressプラグインでこれを使用するのが合理的だと思います（主に実際に行われているため）。

@piehご説明いただきありがとう

一時的なワードプレスソースの修正に関して、私の唯一の他の質問はここで何をするかです

https://github.com/njmyers/byalejandradesign.com/blob/d56b1938f6d1bc22c3cf2282bb3198e378fe3561/packages/gatsby-source-wordpress/src/download-media-files.js#L169 -L173

現時点では、ネットワークエラーが発生する可能性があり、downloadMediaFiles関数全体にcatch句が必要です。 エラーをgatsbyに渡すための通常の動作は何ですか？ そのコードをwordpressプラグインに追加して、ネットワークエラーを正しいハンドラーに適切に渡すことができれば幸いです。 たぶん、エラーメッセージとこの問題への参照を表示できますか？ ご協力ありがとうございます！

@njmyersありがとうございます。モノレポ（ package.json参照を含む）を除いて、セットアップを可能な限り忠実に複製していました。 developを実行すると、 gatsby-source-wordpressがないかのようにエラーが発生しました。 すぐにまたここに行きます。

モノレポをより忠実に再現しました。奇妙なことに、取得した依存関係をダウングレードする前の、フォークされていないgatsby-source-wordpressの場合と同様に、 source and transform nodesになっています。

@pieh彼の質問に答えることができます@https

@dustinhortonはい、画像がたくさんある場合は、かなり長い間そこに座っている必要があります。 リモートファイルのダウンロードに失敗した場合、フォークはunhandled promise rejectionをスローします。 そのため、このシナリオを適切に処理するためのメカニズムが必要です。

プラグインのステータスに関するフィードバックを提供するので、ある種のプログレスマネージャーを統合するという話もあったことを別のスレッドで読んだと思います。

Project-root / .cache / gatsby-source-filesystemの下にあるOSファイルシステムを見ると、ダウンロードされているすべてのイメージを確認できるはずです。 私の場合、今では400枚近くの画像になっているので、かなり時間がかかります。 ただし、フォークバージョンを使用する前は、プラグインはエラーでサイレントに失敗し、その後は進行せず、ソースと変換に数時間かかるという問題が発生していました...

レポはありますか？ これまでのところ、自分のサイトの実際の状況でしかテストしていないので、別のサイトで試してみたいと思います。

@njmyersそれがルールです。よろしければ、私にメールを送ってください： [email protected] 、または単に招待状を探してください。 今晩何か準備をします。

got更新すると、私にとってもすべての問題が解決しました。

got@9の問題は、ノード8（https://github.com/sindresorhus/got/releases/tag/v9.0.0）が必要なため、ATMをアップグレードできないことです:(

少なくともgot@8にアップグレードできるはずですが、これで問題が解決するかどうかはわかりません

got@8はRFC 7234準拠のHTTPキャッシングを実装しているように見えるため、gatsby-source-filesystemは独自のファイルシステムキャッシュアダプタを提供できます。 リソースがキャッシュ可能であることを考えると、少なくともソースノードとトランスフォームノードで2回目に費やされる時間を削減する必要があります。

ひや！

この問題は静かになりました。 不気味な静か。 👻

多くの問題が発生しているため、現在、30日間使用されていない状態で問題を解決しています。 ここでの最後の更新から少なくとも20日が経過しています。

この問題を見逃した場合、または開いたままにしておきたい場合は、ここに返信してください。 この問題を未解決のままにするために、「古くない」というラベルを追加することもできます。

Gatsbyコミュニティに参加していただきありがとうございます。 💪💜

@gatsbotまだ問題です。

y'allのブログ投稿を投稿するように依頼されました。 ソースノードとトランスフォームノードでスタックしているため、実行できません。 他の問題を見ましたが、これに対する修正がある場所がわかりません。 これは、最新のアップストリームであるgatsbyjsのフォークです。 私はこれを一度だけ実行させました。 それは常に変換ノードでスタックしています。

構築中にいくつかのサイトからスクリーンショットを取得できませんでした。 午前中に問題のあるサイトを追加します。

@ twhite96問題が発生したばかりで、まだ開いている一時ファイルを（emacsから）削除することで問題が解決しました。それが役立つかどうかは

ですから、これはまだ問題のようです…

gatsby-source-s3を使用して100枚の写真をプルし、それらをシャープに変換するときにも同じ問題に直面します。 誰かが修正を考え出しましたか？

どういうわけか私の問題は（ランダムに？）修正されました。 これが私が行った手順です。（テスト用に）写真の数が少ない新しいs3バケットを作成してから、ビルドを試みましたが、非常に迅速にビルドされました。 それから私は戻って元のバケツから引っ張ろうと決心しました、そして今や突然それは元々何時間も続く49sでうまく構築されました。 バケットリンクの単なる切り替えでストールがどのように修正されたかはわかりませんが、これが誰かがそれを理解するのに役立つことを願っています。 多分それはキャッシュと関係がありますか？

こんにちは、みんな。 この問題が発生したサイトで使用していたローカルプラグインのバージョンを更新しました。 'createRemoteNode'の前に 'better-queue'を使用し、 'concurrentRequests'パラメーターを渡すので、より良い実装だと思います。 'createRemoteNode'はすでにキューを使用しているため、少し冗長ですが、このバージョンに関係なく、最近のgatsbyアップグレードでうまく機能し、ファイルの進行状況に関するフィードバックを提供します。 このために一緒にPRをしようと思います。 遅れて申し訳ありませんが、私はこれに早く取り組むと言ったのですが、かなり忙しかったです！

https://github.com/njmyers/byalejandradesign.com/blob/wordpress-plugin/packages/gatsby-source-wordpress/src/download-media-files.js

@njmyers

本当にありがとう。 あなたのバージョンは私が抱えていたいくつかの問題を解決しました。 これを1行か2行と組み合わせて、25 GBのmp3のダウンロードを除外しました。これで、設定が完了しました。

間違いなくまだ問題です。
私は過去24時間プロジェクトをコンパイルしようとしてきました。 約12回の試行から、3回は出力と実際のWP接続で成功しました。 これに対する修正はありますか？
ところで、私はプラグインの@njmyersバージョンを使用しようとしましたが（実際には素晴らしい仕事です！）、結果はまちまちでした。 時々それはwordpress_parentまたはDateについて文句を言い、最終的にはクラッシュしますが、これらのエラーで実際に何が起こっているのか理解できませんでした。 他のビルドでは、さまざまなエラーが発生します（ただし、コンパイルは行われますが、これは興味深いことです）。これにより、実際にGraphQLで問題が発生します。

@lucassilvagcいくつかの出力を投稿できますか？ 人々がブランチを試し、テストしてくれてうれしいです。 PRを開くことができるように、それをより良く機能させましょう！

@njmyersもちろんです！

何が起こっているかの簡単な概要：

私のウェブサイトは現在1940までの画像ファイルで実行されていますが、複数の画像ファイルを複数回作成することによるWordPressのせいかもしれません。 バニラ_gatsby-source-wordpress_を使用すると、問題は意図したとおりに表示されます（昨日の夜に別のビルド環境で作成した「バニラ」ビルドがあります。これにより、この問題について話し合っているのと同じ問題が返されます。これはビルドは機能し、すべての画像ファイルが返されるときにコンパイルされます）。 プラグインを使用する（node_modules / gatsby-source-wordpress内のすべてのファイルを置き換える（これが間違っている場合は修正してください））ことにより、_gatsbydevelop_は次のように返します。

TypeError: Cannot read property 'wordpress_parent' of undefined

  - normalize.js:287 entities.map.e
    [amazingtec]/[gatsby-source-wordpress]/normalize.js:287:11

  - Array.map

  - normalize.js:286 Object.exports.mapElementsToParent.entities [as mapElementsToParent]
    [amazingtec]/[gatsby-source-wordpress]/normalize.js:286:12

  - gatsby-node.js:134 Object.exports.sourceNodes
    [amazingtec]/[gatsby-source-wordpress]/gatsby-node.js:134:24


warning The gatsby-source-wordpress plugin has generated no Gatsby nodes. Do you need it?
success source and transform nodes — 299.757 s
success building schema — 10.192 s

しばらくすると、次のように出力されます。

'Cannot query field "allWordpressPage" on type "Query". Did you mean "allSitePage"?',
    locations: [ [Object] ] } ]
error UNHANDLED REJECTION

  TypeError: Cannot read property 'allWordpressPage' of undefined

  - gatsby-node.js:54 graphql.then.result
    C:/Projects/amztec-gtby/amazingtec/gatsby-node.js:54:36

PS：これはgatsby-source-wordpressのバニラビルドであり、前述のように、ファイルを置き換えることで「変換」されました。 すべてのページをクエリできないという事実は、ノードが生成されていないことに関係していると思います。 また、このビルドは、この問題が発生しないときに機能する私のバニラビルドと同じであることに注意してください。

また、ルートを追加すると、同じ初期の問題が発生するように見えることにも注意してください（関連していない、またはWordPress上の複数の保護レイヤーが原因でエラーを返す別のページを避けたかったため）。 私がリストしたルートが正しいかどうか、または後で何かが足りないかどうかはわかりません。

私はあなたの返事にとても満足しています、この問題は現在私のプロジェクトへの大きな後退であり、あなたがまだこの問題に取り組んでいることを嬉しく思います。 どうもありがとう！

acfフィールドと4000画像の400以上のカスタム投稿で同じ問題が発生します。

取得を更新し、35分でビルドできました

gotを更新した後、再度ビルドできません

予想通り、このバグはまだgatsby-wordpressに存在するためです。 すべての画像をダウンロードして処理するのに35分かかると、すべての要素（平均インターネット速度、処理能力、ファイルの総数など）を考慮すると、非常に長い時間がかかります。
@njmyersバージョンを特定の用途に適合させてみることができます。これは、所有しているすべての画像ファイルをダウンロードする際の魅力のように機能します。

予想通り、このバグはまだgatsby-wordpressに存在するためです。 すべての画像をダウンロードして処理するのに35分かかると、すべての要素（平均インターネット速度、処理能力、ファイルの総数など）を考慮すると、非常に長い時間がかかります。
@njmyersバージョンを特定の用途に適合させてみることができます。これは、所有しているすべての画像ファイルをダウンロードする際の魅力のように機能します。

画像の数が少ないときはサイトは正常に機能していましたが、追加を開始するとこれも発生します。

@MWalid got更新するにはどうすればよいですか？ ありがとう。

一日中構築しようとして成功しませんでした。 約1450枚の画像があります。

現在、2日間デプロイできていません。 誰かが私にこれがコードのどこで起こっているかについて正しい方向を示すのを手伝ってくれるので、私は解決策を見つけることができますか？

現在、2日間デプロイできていません。 誰かが私にこれがコードのどこで起こっているかについて正しい方向を示すのを手伝ってくれるので、私は解決策を見つけることができますか？

あなたがアップグレードしたgotの入れ子に依存gatsby-source-filesystem少なくともバージョンの使用に9.4.0 ？

そうでない場合は、以下を追加する必要があります。

  "resolutions": {
    "gatsby-source-filesystem/got": "9.4.0"
  }

Gatsbyプロジェクトのpackage.json 。 次に、 node_modulesとyarn.lockファイルを削除して、再度インストールします。

注：このresolutions機能は、 yarnのみ機能します。 npmはまだこれを実装していません。

@anagstefヒントありがとう

gatsby develop実行しているときに、コマンドが起動されるたびにリモートデータをフェッチする代わりに、ローカルキャッシュを保持する方法はありますか？

@anagstefは、はるかにうまく機能しているようです。 ヒントをありがとう！

このバージョンのgotを使用してビルドすると、出力は非常に冗長になります。 これを削除する方法があるかどうか知っていますか？

@nratterそれがあなたのために働いてうれしいです！

はい、私はそれを知っています、それは非常に冗長であり、それをオフにすることはできません。 すべての有用なコンソール出力を台無しにします。

私が行ったいくつかの調査の後、私はそれがここで引き起こされていると思います：
https://github.com/gatsbyjs/gatsby/blob/80c7023a8bc23886939205fe52e305277294e6af/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L155

ご覧のとおり、 downloadProgressイベントが発生するたびに、各ファイルのダウンロードの進行状況とともにconsole.logが呼び出されます。これは、1秒間に何度も発生します。 古いgotバージョンはdownloadProgressイベントを実装していないため、これは以前は問題ではありませんでした。

たぶん私たちはPRでそれを修正することができますか？ 残ったコードをデバッグしているようです。

同じ問題が発生し、「ソースノードと変換ノード」でスタックしました。 多くのconsole.logsの後、私の問題は、wordpressからのメディアファイルの取得に関するタイムアウトの問題であることになりました。 問題は、サーバーがそれを処理できないことではなく、クラウドフレアのレート制限と約350のリクエストの後にタイムアウトをスローすることでした。

cloudflareをバイパスし、vpsに直接アクセスすると、「ソースノードと変換ノード」が表示されなくなり、ビルドが終了します。

私の回避策は、テスト用のローカルワードプレスを用意することでした。ライブサイトはnetlifyにありますが、デプロイしても問題は発生しませんでした。

皆さん、私はcreateRemoteFileNodeリクエストを並列ではなくシリアルで実行することで、これを修正することができました。

これが私が使用している関数です：

/**
 * Map over items array using the fn function but wait for each step to finish before moving to the next one
 */
exports.serialMap = async (items, fn) => {
  const results = []
  for (const item of items) {
    const result = await fn(item)
    results.push(result)
  }
  return results
}

これが私がそれをどのように使っているかです：

const imageNodes = await serialMap(node.___originalImages, imgUrl => {
  return createRemoteFileNode({
    url: imgUrl,
    parentNodeId: node.id,
    store,
    cache,
    createNode,
    createNodeId,
  })
})

画像がダウンロードされた後、ソースと変換の手順は次のようになります

Downloading remote files [==============================] 1063/1063 156.1 secs 100%
Downloading remote files [==============================] 1064/1064 157.2 secs 100%
Downloading remote files [==============================] 1065/1065 158.4 secs 100%
Downloading remote files [==============================] 1066/1066 159.5 secs 100%
Downloading remote files [==============================] 1067/1067 160.5 secs 100%
Downloading remote files [==============================] 1068/1068 161.5 secs 100%
Downloading remote files [==============================] 1069/1069 162.6 secs 100%
Downloading remote files [==============================] 1070/1070 163.7 secs 100%
Downloading remote files [==============================] 1071/1071 164.9 secs 100%
Downloading remote files [==============================] 1072/1072 166.0 secs 100%
Downloading remote files [==============================] 1073/1073 167.5 secs 100%
Downloading remote files [==============================] 1074/1074 169.2 secs 100%
Downloading remote files [==============================] 1075/1075 171.0 secs 100%
success source and transform nodes — 175.271 s

それがあなたの問題も解決することを願っています。
乾杯

@ancashoriaこのコードはどこに置くべきですか？

@ancashoriaはい、このコードをどこに配置する

これは、 gatsby-source-wordpressプラグインとは多少関係ありません。 上記のコードはgatsby-node.jsます。 これらのリクエストをすべて並行して起動すると失敗するという考えなので、ヘルパー関数を次々に起動するように作成しました。

gatsby-source-wordpressも同様の問題があると思いますが、あまり詳しくありません。
申し訳ありませんが、これ以上のサポートはできません。

それは巨大な画像と遅いインターネット接続に関連しているようです。 Netlifyはサイトを構築できましたが、ダウンロードが1MB /秒しかないため、30秒後にタイムアウトになり、大きなイメージで失敗したため、ローカル接続はできませんでした。

1GBのファイバーがあり、「大規模な」画像はありません。

ブログの画像をワードプレスでダウンロードした後、ローカルで変換するのではなく、単にURLを使用します。 この場合、これらの画像のダウンロードを無効にする設定があれば便利です。

皆さん、私はcreateRemoteFileNodeリクエストを並列ではなくシリアルで実行することでこれを修正することができました。

ええ、この問題は、 createRemoteFileNodeが200の同時実行性を使用しているという事実に基づいています。これは、ほとんどのWPサーバーには多すぎます。 CloudFrontに画像があり、そこでいくつかのレート制限に達していた。

しばらくの間、ソースプラグインの分岐バージョンで問題を修正しようとしましたが、問題は実際にはgatsby-source-wordpressにはなく、 gatsby-source-filesystemます。 理想的には、 createRemoteFileNode関数のコンシューマーは、そこで並行性を渡すことができます。 次に、プラグインは、構成で同時実行オプションを使用できるようにすることができます。 私はまだこの問題に対処するためにPRをしたいと思います！

私が使用している解決策は、 node_modules内のコードを変更するための単純なスクリプトです。 非常に壊れやすく、理想的ではありませんが、並行性を直接変更するのは簡単なハックです。 shelljs使用するため、Windowsユーザーでも機能するはずです（試したことはありません）。

#!/usr/bin/env node
const path = require('path');
const shell = require('shelljs');

const FILE_PATH = path.resolve(
  __dirname,
  // add path to your root dir here,
  'node_modules',
  'gatsby-source-filesystem/create-remote-file-node.js'
);

shell.sed('-i', 'concurrent: 200', 'concurrent: 20', FILE_PATH);

同じ問題が発生し、「ソースノードと変換ノード」でスタックしました。 多くのconsole.logsの後、私の問題は、wordpressからのメディアファイルの取得に関するタイムアウトの問題であることになりました。 問題は、サーバーがそれを処理できないことではなく、クラウドフレアのレート制限と約350のリクエストの後にタイムアウトをスローすることでした。

cloudflareをバイパスし、vpsに直接アクセスすると、「ソースノードと変換ノード」が表示されなくなり、ビルドが終了します。

これはまさに私の問題でした。 Netlifyは非常に高速に構築されていました-2分未満。 投稿は約30件、ソース画像は約500件です。 ローカルですべてが完了したわけではなく、CloudFlareのステータスをDNSにするためにチェックを外すだけで、問題はすぐに解決されました

同じ問題が発生し、「ソースノードと変換ノード」でスタックしました。 多くのconsole.logsの後、私の問題は、wordpressからのメディアファイルの取得に関するタイムアウトの問題であることになりました。 問題は、サーバーがそれを処理できないことではなく、クラウドフレアのレート制限と約350のリクエストの後にタイムアウトをスローすることでした。
cloudflareをバイパスし、vpsに直接アクセスすると、「ソースノードと変換ノード」が表示されなくなり、ビルドが終了します。

これはまさに私の問題でした。 Netlifyは非常に高速に構築されていました-2分未満。 投稿は約30件、ソース画像は約500件です。 ローカルですべてが完了したわけではなく、CloudFlareのステータスをDNSにするためにチェックを外すだけで、問題はすぐに解決されました

私もそうだと思いました。 以前、ビルドが失敗する原因となったイメージが1つあり、Cloudflareが問題であると却下しました。 それ以来、この問題は最近再発し、

これはWPソースの問題だけではないことをエコーし​​たかっただけです— gatsby-source-prismicで同じ問題が発生し、 @ njmyersハックでsour-filesystemの同時実行性が減少したため、レートであると推測しました制限/過負荷の問題。

ソースファイルシステムの同時実行性を構成できるようにする必要があることに同意します。

@njmyers申し訳ありませんが、この修正はどの程度正確に実行されますか。 ビルドの前にスクリプトを実行するだけですか、それともビルドプロセスでスクリプトを参照する必要がありますか。現在、この修正をローカルで、またたとえばnetlifyに適用する方法を自問しています。

@alexanderweとにかくばかげたハックである心配はありません。 node_modulesをインストールした後に実行できます。 私は確かに100％ではないが、私は信じてpostinstallプロジェクトでpackage.json働くだろうファイル。

私の場合、500を超える画像が含まれているjsonを使用すると、Gatsbyは「ソースノードと変換ノード」で50％の時間ハングします。 私はgatsby-source-custom-apiを使用しています

画像は高速で安定したサーバーでホストされます。
私のインターネット接続も高速で安定しています。

"gatsby": "^2.9.4",
"gatsby-image": "^2.1.4",
"gatsby-plugin-emotion": "^4.0.7",
"gatsby-plugin-sharp": "^2.1.5",
"gatsby-plugin-typography": "^2.2.13",
"gatsby-source-custom-api": "^2.0.4",
"gatsby-transformer-remark": "^2.4.0",
"gatsby-transformer-sharp": "^2.1.21",

それをデバッグするために何ができますか？

この問題は、gatsby-source-custom-apiまたはsource-wordpressでのみ発生しますか？

それは私にも起こります。 提案されたすべての修正を試しましたが、何も機能しないようです。 他のサービスでも同様の問題が発生していると聞いていますが、WordpressをGatsbyのバックエンドとして使用することは絶対にありません。

@alexanderweこれを修正する適切な方法は、@ njmyersによって提案されたパッチを実装することです。
次に、 gatsby-source-wordpressなどに別のPRを導入して、 gatsby-config.js参照からこれを実際に構成可能にします。

@sebastienfiこのhttps://github.com/gatsbyjs/gatsby/issues/14819#event-2418874313と対応するコミットhttps://github.com/gatsbyjs/gatsby/commit/90aa24787b32ef9613b6becbfadab6029ec39ce9#diff-1864dd218に遭遇しました同時実行率を構成するための環境変数を追加しました。これにより、問題が解決しました。 環境変数と構成パラメーターについての継続的な議論もあります： https ：

GATSBY_CONCURRENT_DOWNLOADを小さい数値に設定してみましたか？ デフォルトでは200に設定されています。

Linux / Mac：
GATSBY_CONCURRENT_DOWNLOAD=5 gatsby build

ウィンドウズ：
setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build

@wardpeet
試しましたが、何も変わっていません

ログは画像が正常に取得されたことを示しているので、それは間違いなくソースファイルシステムと関係があります....問題はまだ巨大です...私たちは締め切りに遅れて実行しています、そして私たちは本当に探していますこれに対する解決策...

デバッグするようにワードプレスのソースプラグインを設定した後、私はこれを見る

常に470から480の間で電話を切ります...しかし、通常は同じ場所ではありません。

コードのどこでこれが実行されているか誰かが知っていますか？

VPNを途中で切り替えることで動作させることになりました

誰かが自分のリポジトリを私と資格情報と共有して、これを試して問題を見つけようとすることができますか？

[email protected]で私にプライベートメールを送ってください

私のリポジトリはこの時点では簡単に再作成できません。どこかにあるようにデータベースのバックアップがありますが、サイトを構築するために、何年にもわたるコンテンツのために、毎月の価値のある投稿を1つの投稿に減らす必要がありました。

@wardpeetから、私のリポジトリWard（[email protected]）にメールが届きました。 どうなるか教えてください。

当社はwifiを変更し、帯域幅を増やしました。 今日は画像のダウンロードに問題はありませんでしたが、それでもわかりません。ネットワークなのか、それとも並行性なのか。

ただし、Netlifyのすべてのビルドは失敗します...

5:13:43 PM：=== [wordpress__wp_mediaを取得] === https://wildkiwi.com/wp-json/wp/v2/media
5:13:43 PM：エンティティの総数：1717
5:13:43 PM：要求されるページ：344
5:13:45 PM：リクエストはエラーコード「undefined」で失敗しました

エラーコードは未定義なので、何が起こっているのかよくわかりません...

同時リクエストを5に変更すると、Netlifyで機能します

別のプラグイン（https://github.com/angeloashmore/gatsby-source-prismic）でこの問題が発生し、 GATSBY_CONCURRENT_DOWNLOAD=50を設定するとうまくいきました。

これは突然起こったものであり（ある日は私のサイトが構築され、次の日は変更されずに構築されます）、エラーメッセージがないので、これに自信がなくてもクライアントにWebサイトを展開するのは少し戸惑います。二度と起こらない。

基本的に一度に200枚の画像をダウンロードしますが、これは一部のコンピューター/インターネット接続では問題になる可能性があります。 良い解決策は、いくつかの再試行メカニズムでベイクすることです。

私はこれらの問題を抱えていましたが、無料バージョンのhttps：//を使用して、 setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby buildとすべての画像（一部の画像のサイズとファイルサイズが大きすぎる）を組み合わせてビルドを正常に機能させることができました。 en-gb.wordpress.org/plugins/wp-smushit/。

こんにちは！ 作成しているソースプラグイン（WordPressとは関係ありません）で同じ問題が発生し、APIから1000以上の画像をダウンロードするときに発生します。 ほとんどの場合、プロセスの最後にハングします。

GATSBY_CONCURRENT_DOWNLOAD設定しても解決しませんでした。 50 、 20 、 5を試しましたが、運が悪かったです。

APIからサイズのコレクションを取得し、最大の画像を使用していましたが、最小の画像に変更したため、修正もされていません。

この時点で失敗する理由を特定するのは難しいです。私が得るのはsource and transform nodes 、その後は永遠に沈黙します。

このためのデバッグメカニズムがあれば素晴らしいでしょう。

gatsby + wordressの統合でも同じ問題が発生していました。 createRemoteFileNodeを使用していたonCreateNodeAPIでは、ビルドが永久に停止します。

解決策：gatsby-source-filesystemを2.0.4から2.1.8に更新し、GATSBY_CONCURRENT_DOWNLOAD = 50を環境変数に追加しました。

こんにちは👋

私のプロジェクトにも同様の問題があります。

環境

  System:
    OS: macOS 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 10.16.0 - ~/.nvm/versions/node/v10.16.0/bin/node
    Yarn: 1.17.3 - ~/.yarn/bin/yarn
    npm: 6.9.0 - ~/.nvm/versions/node/v10.16.0/bin/npm
  Languages:
    Python: 2.7.15 - /usr/local/bin/python
  Browsers:
    Chrome: 76.0.3809.100
    Firefox: 68.0.1
    Safari: 12.1.2
  npmPackages:
    gatsby: ^2.13.42 => 2.13.42
    gatsby-cli: ^2.7.34 => 2.7.34
    gatsby-image: ^2.2.14 => 2.2.14
    gatsby-plugin-glamor: ^2.1.3 => 2.1.3
    gatsby-plugin-manifest: ^2.2.4 => 2.2.4
    gatsby-plugin-offline: ^2.2.4 => 2.2.4
    gatsby-plugin-react-helmet: ^3.1.5 => 3.1.5
    gatsby-plugin-sass: ^2.1.10 => 2.1.10
    gatsby-plugin-sharp: ^2.2.9 => 2.2.9
    gatsby-plugin-svg-sprite: ^2.0.1 => 2.0.1
    gatsby-source-filesystem: ^2.1.18 => 2.1.18
    gatsby-source-wordpress: ^3.1.12 => 3.1.12
    gatsby-transformer-sharp: ^2.2.5 => 2.2.5

WPサイトに80000を超えるメディアがあります。 npx gatsby developを実行すると、「ENDPLUGIN」の後でスタックします。

...
=== [ Fetching wordpress__TAG ] === https://[WP_REST_API]/wp-json/wp/v2/tags

Total entities : 8805
Pages to be requested : 89
 -> wordpress__TAG fetched : 8805
Fetching the wordpress__TAG took: 12408.827ms
⠀
=== [ Fetching wordpress__wp_partners ] === https://[WP_REST_API]/wp-json/wp/v2/partners
 -> wordpress__wp_partners fetched : 22
Fetching the wordpress__wp_partners took: 1268.292ms
⠀
=END PLUGIN=====================================: 377120.512ms
⠼ source and transform nodes

GATSBY_CONCURRENT_DOWNLOAD値を変更しようとしましたが、何も変更されていません。
メディアの量のインポートを制限する方法はありますか？ 例えば ​​：

{
  resolve: `gatsby-source-filesystem`,
  options: {
    name: `images`,
    path: `${__dirname}/src/images/uploads`,
    limit: 50,
  },
},

ここでも同じ問題があります。セルフホストのWPには1690のメディアがあり、リモートファイルのダウンロード手順の最後で常にスタックします。メディアが1つだけ欠落している場合もあります...

編集：今回のビルドはGATSBY_CONCURRENT_DOWNLOAD=5 yarn build成功しました...

@kvaliumコメントありがとうございます、 GATSBY_CONCURRENT_DOWNLOAD=5 yarn buildは私のために働きました

同じ問題が発生しましたが、ターミナルウィンドウのサイズを変更することでこれを解決できました。

＃4666の最後のコメントを参照してください。

私も同じ問題を抱えていました。 私はそれを解決しました：

rm -r node_modules/ 
rm -r .cache
sudo chown -R login:login . 
fuser -k 8000/tcp 
yarn 
gatsby build
gatsby develop

それが役立つことを願っています

これは奇妙な問題のようです。 これが私の経験です：

• ❌この問題はmacOSHigh Sierraで見ました（iTermを使用）
• ✅ GATSBY_CONCURRENT_DOWNLOAD=50 gatsby developを使い始めたところ、問題は解決しました（これは、数週間の場合でした）
• ❌Mojaveにアップグレードし、グローバルGatsbyインストールを2.7.47にアップグレードしてから、問題が再び発生し始めました（iTermを使用）
• ❌ GATSBY_CONCURRENT_DOWNLOADを5に変更してみました
• ❌ .cacheとnode_modules吹き飛ばしてみました
• ❌ gatsby develop （50と5の両方）の実行中にiTermウィンドウのサイズを変更しようとしました
• ❌iTermではなく「ターミナル」アプリでGATSBY_CONCURRENT_DOWNLOAD=50 gatsby developを実行しました
• ✅2週間後、iTermでGATSBY_CONCURRENT_DOWNLOAD=50 gatsby developを使用してみて、プロセス中にウィンドウのサイズを数回変更しましたが、機能しました。

私はそれを最後のもので実行していると時期尚早に思ったが、それからそれはハングした。 うまくいけば、これは他の人を助けます。 それでも、これは完全には特定されていないようですが、ゆっくりと、しかし確実にそこに到達しています。

更新：今日、これは私のために働いた。 プロセスの適切な時点でiTermウィンドウのサイズを変更したのか、それとも93％から100％に変化するのを見たのかはわかりませんが、今回は何かが異なりました。

GATSBY_CONCURRENT_DOWNLOAD = 5を使用するために、gatsby-node.jsファイルに次のコードを追加します

//国際化
exports.onPostBuild =（）=> {
ChildProcess.execSync（ "ps aux | grep jest | grep -v grep | awk '{print $ 2}' | xargs kill"）
console.log（ 'ロケールのコピー'）
fs.copySync（path.join（__ dirname、 '/ src / locales'）、path.join（__ dirname、 '/ public / locales））
}

532314892 @bradydowling ：

正しいポイントでiTermウィンドウのサイズを変更したためかどうかはわかりません

同じ問題が発生しているときに、iTermウィンドウとbamのサイズを変更しました。これも突然続行されました。 これが偶然の一致なのか、それとも...

@ bradydowling @ davegreggそれは奇妙なことです。 iTermウィンドウのサイズを変更することでうまくいきました。

@TylerBarnesこれが何であれ、Wordpress固有ではないことをお勧めします。 私はWordpressに関連するものは何も使用していません。

@beauhankinsあなたはどうですか？

@davegregg @beauhankins @bradydowlingこれが起こっている場所でレポを共有できる人はいますか？ ターミナルウィンドウのサイズを変更すると問題が解決するのは、本当に奇妙に思えます。

@TylerBarnesyaここに私が見

補足：現在CLIによってインストールされているものよりも古いバージョンのGatsbyを使用してGatsbyサイトのクローンを作成する状況をどのように処理しますか？

私はVScodeターミナルで表彰を実行していました（私はbashを使用しています）。 それは永遠にかかり、上で示唆したように、私はフルスクリーンモードを終了し、それは機能しました。

@bradydowlingリポジトリを共有してございます！ cliより古いバージョンのGatsbyを使用する場合は、開発およびビルド用のnpmスクリプトを作成できます。

{
  "scripts": {
    "develop": "gatsby develop",
    "build": "gatsby build"
  }
} 

次に、 npm run developまたはyarn developを実行すると、プロジェクトのローカルバージョンが使用されます。

この問題を調査していますが、それまでの間、問題のある人はCI=1 yarn build実行することで問題を回避できる可能性があります。これは、舞台裏で別のレポーターライブラリを使用する必要があるためです。 あなたがそれを試してそれがうまくいくなら、私たちに知らせてください！

@dustinhorton ：

v2バージョン@https ：//github.com/dustinhorton/gatsby-v2-issue。 この時点で約50分間構築されています。

Fwiw。 それは約1年前に投稿されたものであり、それ以来ギャツビーは大きく変化しました。 私のマシンで実行すると（そしてpackage.jsonでgatsbyバージョンを*に設定すると）、ビルドは約2000秒（約33分）で完了するようです。
さらに、CLIをアップグレードすると、プログレスバーが表示されます。これにより、より具体的なフィードバックループが得られるため、「感じる」時間の点で大きな違いが生じます。

ソーシングステップは、この時間のほとんどすべて（1968/1975秒）かかります。 リモートファイルのダウンロードはそのほとんどです（1845秒）。

このサーバーへの1回の往復を見ると、これは私を驚かせません。

# Starting requestInQueue, _concurrentRequests= 10
@ requestInQueue for 75 tasks { concurrent: 10 } { id: 'url' }
@ Fetch http://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media?per_page=100&page=4: 2587.339ms
@ Fetch http://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media?per_page=100&page=10: 2661.584ms
@ Fetch http://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media?per_page=100&page=8: 2695.937ms
@ Fetch http://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media?per_page=100&page=2: 2738.339ms
@ Fetch http://dustinhorton.com/gatsby-wp/wp-json/wp/v2/media?per_page=100&page=6: 2853.199ms

各リクエストには約2〜4秒かかります。 探索中に最初にフェッチされる75ページは、合計で18秒かかります（！）。 私は高速接続を持っており、プレーンなwgetでそのタイミングを再現できます。

したがって、最も長いステップでは、約7500のリソースをダウンロードしようとします。 1回のリクエストに2〜4秒かかることを考えると、それほど時間がかかるのは当然です。

それでも、1845秒のメインダウンロードストレッチ中に一時停止が発生することに気付きました。 これが単にデータをスロットリングしているサーバーであるかどうかはわかりません（同時実行性を5に設定しました）。

私はターミナルの幅を小刻みに動かそうとしました（私はxfce linux、fwiwを使用しています）。それは時折、前進する進歩と一致しましたが、それは因果関係よりも偶然の一致であると今は確信しています。

結論：ダウンロードが遅く、進行が「行き詰まっている」ように見えることを再現できますが、現在、すべての兆候は、サーバーの応答を待っていることが原因であると指摘しています。 さらに、端末の幅はこれに影響を与えないようです。

つまり、非常に特定の幅でプログレスバーを更新しているときに、端末の出力が何らかの理由でスタックする可能性があります。 これはありそうもないことですが、不可能ではありません。 したがって、自分で実行できる再現が本当に必要です（したがって認証はありません）。 そして、サーバーを槌で打つことを望まないので、リモートサーバーに依存しないことが望ましいです。

それに応じて、この問題のラベルを更新します。

@njmyersによってhttps://github.com/gatsbyjs/gatsby/issues/6654#issuecomment-438667221に投稿された再現はもう存在しません

@bradydowlingによってhttps://github.com/gatsbyjs/gatsby/issues/6654#issuecomment-562607399に投稿されたリポジトリには、私が持っていない

@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=7: 25025.257ms
@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=4: 27791.269ms
@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=2: 37817.874ms
@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=5: 38056.989ms
@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=3: 38446.504ms
@ Fetch http://topazandsapphire.com/wp-json/wp/v2/media?per_page=100&page=6: 43799.842ms

このソーシングステップは、スピナーと時折のステップがログに記録されていることを除いて、実際には進行状況インジケーターを表示していません。それでも数分かかるため、それが理にかなっている場合は、少なくとも何らかの進行状況インジケーターを表示できます。

さらに、リソースをフェッチするための平均時間を指摘すると役立つ場合があります。これは、「ギャツビー」が実際には往復によって引き起こされているのに、なぜ遅いのかを示しているためです。

このレポジトリでは、589個のリモートファイルをダウンロードするだけでも約5分かかり、プログレスバーが明確な理由もなく動かなくなってしまうことがよくあります。

ブートストラップ後、ファイルが欠落しているため、ビルドが失敗します。

@pvdzこれをもう一度

しかし、あなたの投稿を要約すると、特定の（ダウンロード）ステップには非常に長い時間がかかり、完了するまでもっと長く待つ必要があると言っていますか？

@bradydowlingええ、そうですね。 :)

FTR：リソースの収集を少し追跡しました。 タイミングに光を当てるために;

Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6084.jpg: 15605.630ms
Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6036.jpg
Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6051.jpg: 6447.272ms
Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6034.jpg
Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6045.jpg: 6944.355ms
Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6029.jpg
Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6036.jpg: 6401.541ms
Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/01/IMG_6027.jpg

これらは6MBのファイルです。 私は250Mbsの接続を使用しており、1mbsよりも高速に処理できますが、ダウンロード時間が長くなることは驚きではありません。 cliのサイズ変更の量がそれをスピードアップすることはありません;）

面白い。 これはEC2でホストされている標準のWordPress個人ブログであるため、巨大なインストールではありません。 おそらくこれは、これらすべての要求がホストに過負荷をかけているためです。 または、私はWordPressの専門家ではありませんが、REST API呼び出しに発生する可能性のある標準的なWPレート制限があるのではないでしょうか？ また、この動作はこのサイトに固有のものではないことを前提としています。

おそらくこれは、これらすべての要求がホストに過負荷をかけているためです。

これは私の推測です（またはこの球場の何か）。 しかし、抽象化によって効率が低下していないかどうかを確認するために、独自のアーキテクチャを少し調べています。 しかし、プレーンなwgets / curlで報告されたほとんどの時間を模倣できることを考えると、そこに多くのことがあるとは思えません。

そこで、 got.stream()ビットをダムの生のダウンローダーに置き換えました。

    let r = ""
    require("http").get(url, res =>
      res
        .on("data", m => (r += m))
        .on("end", () => {
          console.timeEnd("$$ Fetch time for " + url)
          resolve(r)
        })
    )

$ Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/05/IMG_5260.jpg
$$ Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/09/TRAVEL-LEISURE-2-copy.png: 1003.535ms
$ Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/05/International-Travel-Topaz-Sapphire.png
$$ Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/09/IMG_4606.jpg: 3174.126ms
$ Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/05/Brunch-Topaz-Sapphire-2.png
$$ Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/09/IMG_4647.jpg: 9521.157ms
$ Started actually fetching http://topazandsapphire.com/wp-content/uploads/2016/05/IMG_6978.jpg
$$ Fetch time for http://topazandsapphire.com/wp-content/uploads/2016/05/International-Travel-Topaz-Sapphire.png: 3611.910ms

そうです、（少なくともこの場合は）長い遅延はダウンロードが原因であると確信しています。 したがって、おそらく私たちの最善の策は、ダウンロードを待っている間にフィードバックを改善することです:)

多くの人が、ターミナルウィンドウのサイズを変更すると（奇妙な理由で）、「ソースノードと変換ノード」でスタックしている開発プロセスが解決されると言います。

残念ながら、WSLを使用する場合、これは解決策ではありません。 ビルドと開発でローカルに「ソースノードとトランスフォームノード」でスタックします。 Netlifyビルドは機能しますが、ローカル開発は不可能になっています。

@Vacilandoは、ソーシング中にサイトにダウンロードされているいくつかのリンクをデバッグし、それらが高速にダウンロードされるかどうかを手動でテストできますか？ 上で述べたように、私が見ている大きな問題の1つは、特定のwpホストが単純に非常に遅いということです。

したがって、ホストが遅く、ダウンロードするコンテンツがたくさんある場合は、このステップで実行する必要があるのはそれだけなので、このステップには多くの時間がかかります。 コンテンツを見つけてダウンロードしてください:)

すべてのステップの一部でコンテンツ自体がダウンロードされることを確認した場合は、ここに戻って丸で囲んでください。 その場合、再現は非常に役立ちます:)

おそらく理想的な世界では、キャッシュするgatsbyにフラグを渡すことができます
サイトアセットのダウンロード。これを繰り返し行う必要はありません。

別の最適な解決策は、ある種のフラグを設定できるようにすることです。
アセットのダウンロードをレート制限またはスロットルして、バストしないようにする
ザ・ホスト。

これらの2つのアイデアについて何か考えはありますか？

木、2019年12月19日には、18:09ピーターファンデジー[email protected]
書きました：

@Vacilando https://github.com/Vacilandoは、いくつかのリンクをデバッグできますか
ソーシング中にサイトにダウンロードされ、手動でテストされます
彼らが速くダウンロードするかどうか？ 私が上で述べたように、私がしている1つの大きな問題
見てみると、特定のwpホストは単純に非常に遅いです。

したがって、ホストが遅く、ダウンロードするコンテンツがたくさんある場合は、そうです
このステップは、それが行うべきすべてであるため、多くの時間がかかります
このステップ; コンテンツを見つけてダウンロードしてください:)

コンテンツ自体がダウンロードされていることを確認した場合は、
ステップ全体、ここに戻って丸で囲んでください。 その場合、再現は
非常に役に立ちました:)

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gatsbyjs/gatsby/issues/6654?email_source=notifications&email_token=ABS4AU62367MTEWP7LJXWTLQZP5L5A5CNFSM4FLHT3T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ABS4AU7GCV4YMZQH6R37BSDQZP5L5ANCNFSM4FLHT3TQ
。

その@bradydowlingの部分はすでに実際に存在しています。 環境変数GATSBY_CONCURRENT_DOWNLOADを設定して、同時リクエストの制限を構成できます。 gatsby-source-wordpress https://github.com/gatsbyjs/gatsby/issues/19292の次のメジャーバージョンでは、メディアファイルのダウンロード方法をより詳細に制御できます。 キャッシュに関しては、ダウンロードされたファイルは現在キャッシュされていますが、gatsby-*。jsファイルを変更すると、古いキャッシュが予期しないバグを引き起こすのを防ぐために、現在キャッシュが消去されます。 つまり、これはgatsby-source-wordpress固有ではなくコアの問題ですが、Gatsbyのキャッシュを改善するための作業は常に行われています。

部分的にJobsApi（＃19831）は、このキャッシュの問題を修正する必要があります。

ええ、私はGATSBY_CONCURRENT_DOWNLOADについて少し上に近いところを見ました。 私の経験から、それは役に立たなかったので、私の提案は、mb per s / m / hなどのよりきめ細かい制御に向けられたと思います。 多分私はナンセンスを言っているだけです。

@bradydowling指数バックオフを使用したリクエストの再試行を追加することと、それが十分に機能しない場合の1秒あたりの最大リクエスト数のオプション設定を追加することを検討しています。

ひや！

この問題は静かになりました。 不気味な静か。 👻

多くの問題が発生しているため、現在、30日間使用されていない状態で問題を解決しています。 ここでの最後の更新から少なくとも20日が経過しています。
この問題を見逃した場合、または開いたままにしておきたい場合は、ここに返信してください。 この問題を未解決のままにするために、「古くない」というラベルを追加することもできます。
わかりやすい注意として、この問題またはその他の修正された問題を確認する最善の方法は、プルリクエストを開くことです。 PRの開始、問題のトリアージ、および貢献の詳細については、 gatsby.dev / contributeを確認してください。

Gatsbyコミュニティに参加していただきありがとうございます。 💪💜

これを閉じます。

ワードプレスの調達に問題があると思われる場合は、最初にワードプレスサーバーの速度が遅いことが原因で遅延が発生していないことを確認してください。 次に、_new_の問題を開いてください（ただし、この問題に戻ってください）。

コメントの数が多いと、ディスカッションを追跡するのが非常に困難になります。 したがって、新しい問題を開くと、特定の問題が回答を得る可能性が高くなります。

私と他の人は過去1年半にわたってそれを確認しました。 私の最初の問題はよく調整されたvpsにありました。 @njmyersにはおそらく修正、または少なくとも改善がありましたが、メンテナからそれをどのように実行したいかについての回答を得ることができませんでした。

私は自分自身を閉鎖することを考えましたが、適度に大きなワードプレスサイトはまだギャツビーには適していないという警告としてそこにある必要があると思います。

@dustinhortonわかりました。 この問題は1年半以上前のものであり、状況は急速に変化しています。 これだけ多くのコメントが寄せられている問題で、実際の問題を理解することはもはや困難です。

Fwiwは、上記のように、最後に報告された再現をチェックし、少なくともそれらが遅いリモートによって引き起こされたものであると判断しました。 高速リモコンで現在のGatsbyリリースの再現がある場合は、このスレッドにすでに投稿されている場合でも、お知らせください。 または、新しい問題を開いて（そして私にタグを付けて）、もっと焦点を当てたい場合は、それをあなたに任せます:)

（_明確にするために、トピック外のメッセージが多すぎて少し古くなったため、この問題を閉じました。それは意図ではなく、ここでの作業が終了していないことを認識しているため、議論を押しつぶしているとは思わないでください。 ！_）