Können Sie ein Reproduktionsrepo erstellen? Die Anzahl der Beiträge sollte kein Problem sein (zumindest in diesem Schritt) - v1 könnte zu Speicherproblemen kommen, aber dies wäre in einem späteren Build-Schritt und sollte nicht stecken bleiben

War neugierig, ob es ein Problem mit Local by Flywheel war , und konnte die Site erstellen, wenn WordPress über MAMP Pro bereitgestellt wurde .

Aber ich erstelle noch nicht einmal Beitragsseiten (erbaue die Seiten), und die Ausführungszeit für diesen problematischen Schritt beträgt 636,41 Sekunden (knapp 11 Minuten).

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,
      //  })
      //})
    })

Bearbeiten: Aktivieren Sie einfach createPage für Beiträge und die Ausführung dieses Elements wurde auf 14 Minuten erhöht. Brutal, aber auch interessant, dass es für ~9000 weitere Items nur 3 Minuten länger dauert. Es sitzt derzeit lange Zeit auf ⠁ run graphql queries .

edit: das lief für 419.470 s oder 7 minuten.

@pieh Whoops, habe das gepostet, bevor ich gesehen habe, dass du gerade geantwortet hast. Ich kann morgen versuchen, diese Site aus der Ferne einzurichten.

Und dazu gedacht, dass diese letzte Zeile über Local hängt und über MAMP ewig dauert.

$ 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 Habe nicht bestätigt, dass dies erfolgreich erstellt wird (jetzt mit der WordPress-Fernbedienung, es dauert Stunden), aber es zeigt sicherlich das Problem: https://github.com/dustinhorton/gatsby-issue

Sollte in der Lage sein, das einfach zu klonen und zu bauen.

Nur zweimal über 10 Stunden gelaufen, ohne dass das Gebäude fertig gestellt wurde. Bitte lassen Sie mich wissen, was ich sonst noch für die Fehlerbehebung bereitstellen kann.

Könnten Sie versuchen, auf v2 zu aktualisieren? Wir haben eine Menge Geschwindigkeitsverbesserungen an verschiedenen Gatsby-Subsystemen vorgenommen, die große Sites wie diese dramatisch beschleunigen sollten.

@KyleAMathews Ich werde das heute Abend

@KyleAMathews v2-Version @ https://github.com/dustinhorton/gatsby-v2-issue. Baue zu diesem Zeitpunkt etwa 50 Minuten.

Töte es jetzt. Die Site wurde immer noch nicht erstellt.

Sie können auch versuchen, die Ablaufverfolgung zu aktivieren https://next.gatsbyjs.org/docs/performance-tracing/

Wir haben gatsby-source-wordpress noch keine Tracing-Unterstützung hinzugefügt, aber die Tracing-Berichte können Ihnen helfen herauszufinden, wo es steckenbleibt.

Wenn jemand anderes daran interessiert ist, sich damit zu befassen, wäre es eine großartige PR, gatsby-source-wordpress Tracing-Unterstützung hinzuzufügen. Lass mich wissen, wenn du interessiert bist!

Ich muss leider aussteigen, da ich meine ganze Zeit damit verbringen muss, auf ein traditionelles Thema zu portieren – irgendwie niedergeschlagen, um Gatsby nicht verwenden zu können. Alles andere fühlt sich so rückständig an.

Entschuldigung, wir hatten keine Gelegenheit, uns das anzusehen :-( Sprinte gerade, um v2 herauszubringen.

Besteht die Möglichkeit, dass Sie die WP-Site laufen lassen? Es scheint definitiv ein Fehler zu sein, der behoben werden sollte.

Ich habe getwittert und um Hilfe gebeten, also wird hoffentlich bald jemand darauf springen :-)

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

Wow, das ist rad – vielen Dank. Die Site geht vorerst nirgendwo hin (und ich werde eine Kopie migrieren und das Repro-Repository aktualisieren, wenn es erforderlich ist).

@dustinhorton für das, was es wert ist, habe ich auch Probleme beim Beiträge ) auf Local by Flywheel im Vergleich zu unserer Produktionsumgebung mit einem davor liegenden CDN festgestellt.

REST-Antworten für Gatsby sind von Local 10-20x länger als von der Produktion, sodass die Erstellung der Site ewig dauert. Ich habe noch keine Zeit damit verbracht, das Problem in Local zu debuggen, aber es steht auf meiner To-Do-Liste :)

@KyleAMathews Ich könnte mir das Hinzufügen von Tracing zu Source-Wordpress ansehen.

@Christophor das wäre toll!

@dustinhorton Ich

Die WP_MEDIA-Anfragen laufen ziemlich schnell mit Ergebnissen, also dachte ich, ich wäre dabei
das ist klar, aber ich kann mir das später in dieser Woche ansehen, wenn du es denkst
kann der Fall sein.

Am Mittwoch, 8. August 2018 um 17:45 Uhr Chris Wiseman [email protected]
schrieb:

@dustinhorton https://github.com/dustinhorton Ich sehe 404's für die
Bilder auf Ihrer Beispielseite (
https://dustinhorton.com/gatsby-wp/wp-content/uploads/2018/07/IMG_9906.jpg,
zum Beispiel), die die Bauzeit aufblähen könnten. Jede Chance, die du könntest
nach den Pfaden für diese suchen?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment-411562589 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAXFNRHTA-vqIwCTtioejUL-Ei3nM0Lbks5uO1vygaJpZM4VZ57n
.

Das stimmt, aber ein Teil des Quell- und Transformationsschritts besteht darin, alle Medienelemente herunterzuladen, die in der REST-Antwort gefunden werden:
https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-wordpress/src/normalize.js#L434

404-Bilder auf 7504-Bildern zu erhalten, kann einige Probleme verursachen ;)

Ich glaube, ich habe alle 404s bereinigt. Werde heute Abend versuchen zu bauen. Danke an alle.

Scheinbar keine Änderung:

~/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

Und es sitzt dort seit ungefähr 8 Stunden.

@dustinhorton welche Art von Hosting verwendest du? Ich denke, es tötet nur Ihre Produktionsbox mit der Menge an Anfragen. Ich glaube, ich habe es geschafft (nach einiger Zeit, nicht einmal acht Stunden), indem ich gleichzeitige Verbindungen auf etwas Niedriges wie 1 oder 2 gesetzt habe.

Es ist ein anständiger VPS auf Linode. Ich kann die Einstellungen anpassen, wenn das hilft. Aber das Problem tritt auch lokal auf.

https://github.com/gatsbyjs/gatsby/blob/46290c2b0e7894fca036bdcc658a5d1936c4221f/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L133 -L159 dies funktioniert manchmal nicht richtig, wenn wir größere Mengen ziehen von Dateien - Netzwerkanfrage wird gelöst, aber der Dateischreibstrom wird nie beendet (oder Fehler ausgegeben). Ich denke, es wäre großartig, nach responseStream Zeitüberschreitung hinzuzufügen, um zu warten, bis fsWriteStream fertig ist, und wenn nicht, alle Ressourcen zu zerstören und erneut zu versuchen, die Datei zu schreiben (möglicherweise einige Wiederholungen machen) und tatsächlich Fehler ausgeben, wenn dies nicht wirklich möglich ist.

@pieh können Sie bitte den aktualisierten Code für diese Datei senden?

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

@aman-developer dafür gibt es noch keinen Fix - sonst würde es veröffentlicht. Das Problem bei diesem Problem besteht darin, dass es keine zuverlässige Möglichkeit gibt, dies zu reproduzieren, sodass alle Korrekturen Vermutungen sind. Das Problem ist in einigen Fällen (möglicherweise Hardware und / oder O spezifisch sein) Dateisystem Writestream nicht beendet und steckt zu bleiben , ohne Fehler zu werfen , um jeden Fix hier wirklich zu umgehen Probleme bei dem Versuch , fs Paket / Hardware / o nicht zuverlässig :/

Hatten Sie Probleme beim Repro mit meinem Repository und meiner Site? Für mich ist es stimmig.

Ich verwende createRemoteFileNode, um Remote-Images abzurufen, und habe das gleiche Problem: Der Download bleibt bei ungefähr 680/780ish hängen.

In createRemoteFileNode gibt es einen Listener für das downloadProgress Ereignis, das in https://github.com/sindresorhus/got/releases/tag/v8.0.0 hinzugefügt wurde, aber gatsby-source-filesystem verwendet got 7.1.0.

Ich habe versucht, ein Upgrade auf die neueste Version 9.2.2 zu machen und konnte nun alle Bilder erfolgreich herunterladen.

Fügen Sie dies in package.json hinzu:

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

Außerdem scheint es in got nach 7.1.0 einige kritische Korrekturen zu geben, wie z. B. Streamfehler, die nicht korrekt weitergeleitet werden usw. (https://github.com/sindresorhus/got/releases/tag/v8.0.1)

Ich habe versucht, got aktualisieren, aber manchmal stecke ich immer noch fest, aber es lohnt sich trotzdem. Beachten Sie nur, dass downloadProgress Sachen entweder deaktiviert oder eine bessere Ausgabe benötigt werden, da das Terminal / die Konsole mit dem Fortschritt gespammt wird, wenn Sie das verwenden

Ich konnte gatsby develop nach ~25 Minuten ausführen, musste jedoch die Parallelität in create-remote-file-node.js von 200 auf 20 reduzieren wieder), nachdem Sie Protokolle in diesen leeren Fang in processRemoteNode eingefügt haben.

Ich bin mir nicht sicher, ob es an got liegt, kann aber vielleicht mit anderen http-Clients experimentieren ...

...
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' }

Ich bekomme die gleichen Fehler mit prismic

Ich habe auf "got": "^9.2.2" aktualisiert, jetzt ist Arbeitszeita!

Wir müssen auf jeden Fall einen Blick darauf werfen, um unsere got Version zu aktualisieren. Dies ist ein intermittierendes Problem, daher könnte es Zufall sein, dass es funktioniert hat. @RobinHerzog bitte lassen Sie es uns wissen, wenn Sie mit der aktualisierten Version von got auf ähnliche Probleme stoßen werden

Das Aktualisieren von got reduzierte die Build-Zeit für mein Repro-Repository erheblich, dauerte aber beim letzten Versuch immer noch fast eine Stunde.

@dustinhorton Welcher Teil des source and transform data da wir nicht explizit zeigen, wie lange das Herunterladen von Dateien dauert)?

Ich habe 150 MB Bilder mit einer 1 GB Internetverbindung. Jetzt funktioniert es. Ich brauche 30 Sekunden zum Herunterladen und Weiterbauen.

Dieses Problem habe ich auch ständig. Das Aktualisieren von got hat das für mich nicht gelöst. Haben Sie Erfolg mit dem Hinzufügen zusätzlicher Ablaufverfolgung zu Source-Wordpress, damit wir versuchen können, das Problem zu beheben?

Ich habe versucht, concurrentRequests und perPage ändern sowie got auf die neueste Version zu aktualisieren, aber keine hat funktioniert. Im Moment kann ich categories , posts , pages und tags , aber wenn ich users oder media , direkt nach =END PLUGIN=== , gibt das Plugin einen Fehler zurück: TypeError: Cannot read property 'id' of undefined .

Wenn ich alle Routen hinzufüge und diejenigen auf die schwarze Liste setze, auf die ich keinen Zugriff habe, bekomme ich =END PLUGIN=== aber es endet nie ... Dies gilt für Tonnen von Websites, die ich getestet habe, also denke ich, dass es irgendwie mein System sein könnte . Wenn das jemand testen möchte, hier ist die Konfiguration:

    {
      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: Eine URL, die ich _durfte_ abrufen konnte, war https://wesbos.com/

HAPPY UPDATE: Ich habe es geschafft, dass es funktioniert (_für kleinere Sites_) mit includedRoutes , sogar mit users und/oder media indem ich taxonomies in die Abfrage aufgenommen habe . Jetzt bekomme ich den 'id' of undefined Fehler nicht :D

@pieh Ich glaube, dass die users und media von taxonomies abhängig sind, also sollten sie vielleicht standardmäßig kommen, wenn die Konfiguration einen dieser Typen enthält? Lassen Sie es mich wissen, wenn ich bei der weiteren Fehlerbehebung helfen kann! Als abschließende Anmerkung, dieser taxonomies Fehler scheint nichts mit dem unendlichen Build-Prozess zu tun zu haben. Bei Sites, die größer als ~500 Mediendateien sind, kann ich den Build-Prozess immer noch nicht abschließen!

UPDATE Nummer 2 : Also, ich habe es geschafft, dass es für queroinvestiragora.com funktioniert, das 600 Mediendateien hat, aber nur 70 Posts, es dauert ungefähr 15 Sekunden nach =END PLUGIN=== , aber es funktioniert. www.clubedospoupadores.com hat jedoch 702 Mediendateien und 336 Beiträge und wird nicht kompiliert.

PS: Meine Konfiguration in diesen Experimenten ist:

    {
      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",
        ],
      },
    },

Hallo,

Ich habe es geschafft, die Ablaufverfolgung mit den hier beschriebenen Schritten hinzuzufügen https://www.gatsbyjs.org/docs/performance-tracing/ . Leider lieferte es nicht viele Informationen, da es mir nur sagte, dass das Quellen und Transformieren von Knoten tatsächlich ziemlich lange dauert.

Ich habe jedoch einige meiner eigenen Fehlersuche zu diesem Problem durchgeführt, nachdem ich ein nicht deterministisches Verhalten mit Bildern hatte. Wenn ich entweder ein Entwicklungs- oder ein Build-Skript ausführte, bekam ich einen Fall, in dem nicht alle Bilder heruntergeladen wurden und die localFile-Knoten nicht abgeschlossen wurden. Nachdem ich in den Code gegraben habe, habe ich festgestellt, dass hier ein Problem zu bestehen scheint

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

Für mich schlug der createRemoteFile-Knoten aufgrund von Server-Timeout-Fehlern fehl und gibt standardmäßig null zurück. Ich musste auch dem createRemoteFile-Knoten einige Protokollierungen hinzufügen, um dies festzustellen und die tatsächlichen Serverantworten zu erhalten. Da diese Knoten nicht abgeschlossen werden und keine IDs haben, werden sie nicht im Cache registriert. Die tmp-Dateien werden gelöscht und das gatsby-source-filesystem war unvollständig. Aus irgendeinem Grund (ich habe noch nicht so weit geschaut) wurde das Quelldateisystem beim erneuten Ausführen des Build-Skripts gelöscht, wahrscheinlich weil das Skript erkennt, dass das Dateisystem ungültig oder unvollständig ist. Es war dieser Prozess, der für mich eine Schleife erzeugte und Fehler bei zukünftigen Builds verursachte, da das Dateisystem nie abgeschlossen wird.

Ich arbeite an einem Fix, der einige der Probleme zumindest bei großen Bildmengen zu lindern scheint. Wenn das Entwicklungs- oder Build-Skript beim ersten Mal erfolgreich alle Bilder heruntergeladen hat, wird es anschließend nicht gelöscht und dann geht der Build-Prozess ziemlich schnell, da die Bilder vom gatsby-source-filesystem richtig zwischengespeichert werden! Mein Build ging von 15 Minuten auf 1 Minute zurück.

Ich bin mir nicht sicher, ob dies mit Builds zusammenhängt, die eine große Anzahl von Beiträgen enthalten. Mein Problem stand in direktem Zusammenhang mit dem Herunterladen von 1,6 GB Bilddaten.

Dies ist das erste Mal, dass ich mit Quell-Plugins für Gatsby arbeite. Wenn also jemand Gedanken oder Ratschläge dazu hat, würde ich mich freuen! Ich sollte mein Repo später heute veröffentlichen können. Ich arbeite daran, dass es meine lokale Version von gatsby-source-filesystem ohne Komplikationen verwendet.

Hallo,

Folge meinem Kommentar von vor ein paar Tagen. Hier ist mein Repo.

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

Ich verwende in diesem Projekt ein Monorepo. Hier sind einige Schritte, wenn Sie das Repository lokal ausführen möchten.

1. Stellen Sie sicher, dass Sie über die neueste Version von Yarn 1.12.3 verfügen
2. Klonen Sie den Plugin-Zweig git clone https://github.com/njmyers/byalejandradesign.com.git -b wordpress-plugin
3. yarn && yarn bootstrap
4. Navigieren Sie zum Ordner Gatsby, damit Sie nur diesen Ordner ansehen können cd packages/web
5. Führen Sie yarn develop oder yarn build-web . Es sollte beim ersten Mal erfolgreich abgeschlossen werden und nachfolgende Ausführungen desselben Befehls führen zu viel schnelleren Builds! Quell- und Transformationsknoten dauern für mich 222s, während es früher dreimal so lange dauerte und / oder nicht abgeschlossen wurde.
6. Wenn Sie sehen möchten, was während des Quellvorgangs und der Transformation tatsächlich passiert, können Sie in Ihrem Dateibrowser unter /packages/web/.cache/gatsby-source-filesystem nachsehen. Sie werden sehen, dass die Dateien dort erstellt werden.

Ich habe die DownloadMediaFiles-Funktion komplett neu geschrieben. Sie können diese Datei unter diesem Link https://github.com/njmyers/byalejandradesign.com/blob/wordpress-plugin/packages/gatsby-source-wordpress/src/download-media-files.js

Es ist wahrscheinlich ausführlicher als es sein muss, aber ich musste dies tun, um herauszufinden, was alles passiert. Die Funktionalität, die ich geändert habe, besteht darin, eine Versprechensablehnung hinzuzufügen, wenn createRemoteFileNode null zurückgibt. Ich verwende dann eine Funktion downloadRunner, um die Anfragen zu drosseln, damit sie nicht alle gleichzeitig auf dem Server landen, sowie einen Wiederholungsversuch bei Ablehnungen von Zusagen. Ich habe zwischen jeder createRemoteFileNode-Anforderung eine 200-ms-Drosselung hinzugefügt. Ich bin mir sicher, dass dieser Wert optimiert werden könnte und einige davon könnten besser geeignet sein, um createRemoteFileNode direkt hinzuzufügen.

Wenn jemand neugierig ist, ist die WP-Installation eine EC2-Mikroinstanz, während sich die Images hinter einer CloudFront-Verteilung befinden. Persönlich hatte ich nie Probleme damit, Beiträge zu bekommen, mein Problem war, Bilder zu bekommen, und ich glaube, dass die meisten Probleme, die die Leute haben, darauf zurückzuführen sind.

Auch wenn jemand seine eigene Site verfolgen oder debuggen möchte, empfehle ich, hier zu beginnen ...

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

Ich habe der catch-Klausel eine Protokollierung hinzugefügt und konnte feststellen, dass die Bildknoten nicht korrekt verarbeitet wurden, da ich Zeitüberschreitungsfehler erhielt und dann null zurückgab.

@njmyers Ich createRemoteFileNode direkt verwenden sollten. Wir verwenden dort queue , sodass sich die Benutzer dieser Funktion (in diesem Fall gatsby-source-wordpress ) keine Sorgen machen müssen. Eine potenziell problematische Sache ist die 200-ms-Drosselung - vielleicht könnten wir ohne sie starten und wenn wir Probleme sehen, wenden Sie automatisch die Drosselung an (pro Hostname).

@pieh Ja, das wäre wahrscheinlich der Ort, um diese Logik anzuwenden. Die Drosselung war für mich eine Möglichkeit, dies anzugehen und das Problem zu diagnostizieren, daher stimme ich zu, dass createRemoteFileNode in der Lage sein sollte, dies alleine zu bewältigen.

Besonders problematisch ist jedoch das aktuelle Verhalten, die Fehler stillschweigend zu versagen und null zurückzugeben. Meiner Meinung nach sollte entweder über das Scheitern oder den Erfolg der Operation kommuniziert werden. Ich denke, createRemoteFileNode könnte mit der folgenden Funktionalität robuster gemacht werden.

1) Schaffen Sie eifrig Verbindungen
2) Wenn Fehler vom Server auftreten, beginnen Sie mit der Drosselung und/oder versuchen Sie es bei Bedarf erneut
3) Legen Sie einige vernünftige Standardeinstellungen für Drosselung/Wiederholung fest
4) Erstellen Sie einen Einstiegspunkt zum Anpassen der Drosselung/Wiederholung
4) Lehnen Sie eine Zusage ab, wenn der Knoten aus irgendeinem Grund nicht verarbeitet werden kann.

Ich kann auch sagen, dass ich hier mit Timeout-Werten herumgespielt habe https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L135 - L141. Obwohl dies die Wahrscheinlichkeit einer erfolgreichen Antwort erhöhte, musste ich dennoch die Handhabung hinzufügen, um eine erfolgreiche Antwort zu

Höchstwahrscheinlich wäre hier der richtige Einstiegspunkt für diese Logik.

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

Wenn die Aufgaben fehlschlagen, werden sie erneut versucht und/oder fehlgeschlagen und dann endgültig abgelehnt.

Lesen Sie auch kurz die queue Dokumente. Ich verstehe, was Sie darüber sagen, dass queue in der Lage ist, dies selbst zu verwalten.

@njmyers schöne Ermittlungsarbeit! Stimmen Sie auf jeden Fall zu, dass das Herunterladen von Dateien viel intelligenter sein muss!

Es könnte schön sein, den Datei-Download-Teil in ein eigenes Paket zu extrahieren, das sich auf dieses Problem des Herunterladens und Zwischenspeicherns von Remote-Dateien konzentriert.

Es besteht eine gute Chance, dass wir die Funktionalität an mehreren Stellen in Gatsby und in Zukunft verwenden müssen und es ist etwas, das andere Leute im Internet auch verwenden möchten.

@KyleAMathews meinst du das Extrahieren von createRemoteFileNode in ein separates Paket?

Nein, nur das Herunterladen und Zwischenspeichern von Dateien. createRemoteFileNode würde dann einfach dieses Paket aufrufen und eine Zusage zurückbekommen, die aufgelöst wird, wenn die Datei heruntergeladen (oder aus dem Cache zurückgegeben) wird.

Ich habe dieses Problem auch mit meinem eigenen Cockpit-Quell-Plugin.

Ich sehe, es wäre wirklich eher so, als würden diese Codeteile in ein separates Paket extrahiert ...

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

Dies scheint der Code zu sein, der sich speziell mit dem Herunterladen und Caching befasst. Bitte korrigieren Sie mich, wenn ich falsch liege. Gerne daran mitarbeiten! Ich versuche nur herauszufinden, wie es im größeren Ökosystem funktioniert.

Würde ein PR akzeptiert, nur gatsby-source-wordpress zu reparieren und dann den Fix danach zu extrahieren? Ich habe Probleme mit der Verwendung @njmyers- Plugins, wie es ist, und es scheint eine enorme Verbesserung zu sein.

@dustinhorton nicht sicher, ob dies hilft, aber ich habe festgestellt, dass es am besten ist, gatsby direkt auf die Datei package.json zu verweisen, wenn Sie ein lokales Plugin verwenden möchten. Ich hatte Probleme, Gatsby dazu zu bringen, mein lokales Plugin zu finden, bis ich anfing, es explizit anzugeben.

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

Ich freue mich immer noch, an diesem Problem und sogar dem neuen Plugin wie besprochen zu arbeiten. Ich suche nur nach einer kleinen Anleitung, wie dies integriert werden kann, da es sich wie eine disruptive Veränderung anfühlt, die sich auf viele andere Dinge auswirken könnte, die mir nicht bekannt sind. @KyleAMathews irgendwelche Gedanken? Ich habe immer noch das Gefühl, dass der Code hier ist

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

Ist der Teil, der in ein eigenes Paket extrahiert werden soll. Davon abgesehen ist es eine der Kernfunktionen von createRemoteFileNode und ich möchte sicherstellen, dass ich richtig vorgehe, damit es wieder richtig in das Ökosystem integriert werden kann.

@njmyers Sie haben mit Ihrer Recht - wir möchten auch, dass unsere aktuelle Warteschlange (die ATM auf 200 gleichzeitige Anforderungen begrenzt, was für lokale Entwickler und anscheinend für WordPress nicht gut erscheint) verschoben und wahrscheinlich geändert wird.

@dustinhorton Ich denke, es ist vernünftig, dies zuerst im WordPress-Plugin zu verwenden (hauptsächlich, weil es praktisch fertig ist).

@pieh Vielen Dank für deine Klarstellung! Ich fange an, an einem neuen Plugin zu arbeiten.

In Bezug auf eine temporäre Korrektur der WordPress-Quelle wäre meine einzige andere Frage, was hier zu tun ist

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

Im Moment wäre es noch möglich, Netzwerkfehler zu haben und es muss eine Fangklausel für die gesamte DownloadMediaFiles-Funktion geben. Was ist das normale Verhalten bei der Übergabe von Fehlern an Gatsby? Ich würde diesen Code gerne in das WordPress-Plugin einfügen, um die Netzwerkfehler ordnungsgemäß an den richtigen Handler weiterzugeben. Vielleicht könnten wir eine Fehlermeldung und einen Hinweis auf dieses Problem anzeigen? Danke für deine Hilfe!

@njmyers Danke – ja, ich habe Ihr Setup so genau wie möglich repliziert, abgesehen davon, dass es sich um ein Monorepo handelt (einschließlich des Verweises auf package.json ). Beim Ausführen von develop nur Fehler ausgegeben, als ob es kein gatsby-source-wordpress gäbe. Ich werde es hier in Kürze noch einmal versuchen.

Ihr Monorepo wurde originalgetreuer neu erstellt, und seltsamerweise sitzt es nur bei source and transform nodes , wie es mit dem nicht gegabelten gatsby-source-wordpress war, bevor die erhaltene Abhängigkeit herabgestuft wurde.

@pieh Kann seine Anfrage @ https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -442536931 beantworten?

@dustinhorton Ja, es sollte auch einige Zeit dort sitzen, wenn Sie viele Bilder haben. Mein Fork gibt unhandled promise rejection wenn eine Remote-Datei nicht heruntergeladen werden kann. Aus diesem Grund würde ich gerne einen Mechanismus haben, um dieses Szenario richtig zu handhaben.

Ich glaube, ich habe auch in einem anderen Thread gelesen, dass auch eine Art Fortschrittsmanager integriert werden soll, da dies Feedback zum Plugin-Status geben würde.

Wenn Sie in Ihrem OS-Dateisystem unter project-root/.cache/gatsby-source-filesystem nachsehen, sollten Sie alle Bilder sehen können, die heruntergeladen werden. In meinem Fall sind es jetzt fast 400 Bilder, also dauert es ziemlich lange. Vor der Verwendung meiner gegabelten Version würde das Plugin jedoch bei einem Fehler stillschweigend fehlschlagen und dann nie fortfahren, was zu dem Problem führte, dass Source und Transformation Stunden dauern würden ...

Hast du ein Repo? Ich würde es gerne auf einer anderen Seite ausprobieren, da ich es bisher nur in einer realen Situation auf meiner Seite getestet habe.

@njmyers Das wäre die Regel – wenn es Ihnen nichts ausmacht, [email protected] oder halten Sie einfach nach einer Einladung Ausschau. Ich werde heute Abend etwas vorbereiten.

Das Aktualisieren von got hat auch bei mir alle Probleme gelöst.

Das Problem mit got@9 ist, dass Node 8 (https://github.com/sindresorhus/got/releases/tag/v9.0.0) erforderlich ist, sodass wir ATM nicht aktualisieren können :(

Wir sollten in der Lage sein, mindestens auf got@8 zu aktualisieren, aber ich bin mir nicht sicher, ob dies die Probleme behebt

got@8 scheint RFC 7234-konformes HTTP-Caching zu implementieren, sodass gatsby-source-filesystem seinen eigenen Dateisystem-Cache-Adapter bereitstellen könnte. Dies sollte zumindest die Zeit, die in Quell- und Transformationsknoten verbracht wird, beim zweiten Mal reduzieren, da die Ressource zwischenspeicherbar ist.

Hallo!

Dieses Thema ist ruhig geworden. Gruselige Stille. 👻

Wir bekommen viele Probleme, daher schließen wir Probleme derzeit nach 30 Tagen Inaktivität. Das letzte Update hier ist mindestens 20 Tage her.

Wenn wir dieses Problem verpasst haben oder Sie es offen halten möchten, antworten Sie bitte hier. Sie können auch das Etikett "nicht veraltet" hinzufügen, um dieses Problem offen zu halten!

Danke, dass Sie ein Teil der Gatsby-Community sind! 💪💜

@gatsbot Immer noch ein Problem.

Wurde gebeten, einen Blogbeitrag für euch beizutragen. Kann nicht ausgeführt werden, da es auf Quell- und Transformationsknoten hängen bleibt. Habe das andere Problem gesehen, aber ich sehe nicht, wo es eine Lösung dafür gibt. Es ist eine Gabelung von gatsbyjs, dem neuesten Upstream. Ich habe das nur einmal laufen lassen. Es bleibt immer bei der Transformation von Knoten hängen.

Es schlägt beim Erstellen von Screenshots von einigen Websites fehl. Ich werde morgen früh die anstößigen Seiten hinzufügen.

@ twhite96 Ich bin gerade auf das Problem

Es sieht also so aus, als ob das immer noch ein Problem ist…

vor dem gleichen Problem, wenn Sie gatsby-source-s3 verwenden, um 100 Fotos zu ziehen und sie scharf zu transformieren. Hat jemand eine Lösung gefunden?

Irgendwie wurde mein Problem behoben (zufällig?). Dies sind die Schritte, die ich unternommen habe, ich habe einen neuen s3-Bucket mit weniger Bildern (zum Testen) erstellt und dann versucht, ihn zu bauen, und er baute sehr schnell erfolgreich. Dann beschloss ich, zurück zu gehen und zu versuchen, aus dem ursprünglichen Eimer zu ziehen, und jetzt wurde es plötzlich erfolgreich in 49er gebaut, als es ursprünglich stundenlang ging. Ich weiß nicht, wie der bloße Schalter in den Bucket-Links den Stall repariert hat, aber ich hoffe, dies hilft jemandem, es herauszufinden. hat es vielleicht mit dem Cache zu tun?

Hallo zusammen. Ich habe meine lokale Plugin-Version aktualisiert, die ich für eine Site mit diesem Problem verwendet habe. Ich denke, es ist eine bessere Implementierung, da es 'better-queue' vor 'createRemoteNode' verwendet und den Parameter 'concurrentRequests' übergibt. Es ist ein wenig überflüssig, da 'createRemoteNode' bereits eine Warteschlange verwendet, aber unabhängig davon scheint diese Version mit den letzten Gatsby-Upgrades gut zu funktionieren und gibt Feedback zum Fortschritt der Dateien. Ich werde versuchen, dafür eine PR zusammenzustellen. Entschuldigung für die Verzögerungen, ich weiß, ich habe gesagt, dass ich früher daran arbeiten würde, aber ich war ziemlich beschäftigt!

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

@njmyers

Vielen Dank. Ihre Version hat einige Probleme gelöst, die ich hatte. Ich habe das mit ein oder zwei Zeilen kombiniert, um das Herunterladen von 25 GB mp3s herauszufiltern, und jetzt bin ich fertig!

Definitiv immer noch ein Thema.
Ich habe in den letzten 24 Stunden versucht, mein Projekt zu kompilieren. Von ungefähr 12 Versuchen waren 3 mit Ausgaben und tatsächlicher WP-Verbindung erfolgreich. Gibt es eine Lösung dafür?
Übrigens, ich habe versucht, @njmyers- Version des Plugins zu verwenden (eigentlich tolle Arbeit!), aber die Ergebnisse waren gemischt. Manchmal beschwerte es sich über wordpress_parent oder Date und stürzte schließlich ab, konnte jedoch nicht herausfinden, was mit diesen Fehlern tatsächlich vor sich geht. In anderen Builds treten andere Fehler auf (aber sie kompilieren, was interessant ist), was tatsächlich Probleme mit GraphQL verursacht.

@lucasilvagc kannst du einige Ausgaben posten? Ich bin froh, dass die Leute den Zweig ausprobieren und testen. Lass es uns besser machen, damit wir die PR öffnen können!

@njmyers Klar!

Ein kurzer Überblick über das Geschehen:

Meine Website läuft derzeit mit ~ 1940 Bilddateien, vielleicht ist WordPress schuld, indem es mehrere Bilddateien mehrmals erstellt. Wenn ich ein Vanilla-_gatsby-source-wordpress_ verwende, erscheint das Problem wie beabsichtigt (es gibt einen "Vanilla"-Build, den ich gestern Abend in einer anderen Build-Umgebung erstellt habe - der das gleiche Problem zurückgibt, das wir zu diesem Thema insgesamt besprechen build funktioniert und kompiliert, wenn alle Bilddateien zurückgegeben werden). Indem Sie Ihr Plugin verwenden (alle Dateien in node_modules/gatsby-source-wordpress ersetzen (korrigieren Sie mich, wenn ich falsch liege)) gibt mir _gatsby developer_ Folgendes zurück:

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

Nach kurzer Zeit wird ausgegeben:

'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: Dies war ein Vanilla-Build von Gatsby-Source-Wordpress, der durch Ersetzen der Dateien in Ihre _"konvertiert"_ wurde, wie ich oben sagte. Ich denke, die Tatsache, dass nicht alle Seiten abgefragt werden können, hängt damit zusammen, dass keine Knoten generiert werden. Ich möchte auch bemerken, dass dieser Build meinem Vanilla-Build entspricht, der funktioniert, wenn dieses Problem nicht auftritt.

Ich möchte auch beachten, dass das Hinzufügen von Routen für mich das gleiche anfängliche Problem zu verursachen scheint (da ich verschiedene Seiten vermeiden wollte, die nicht miteinander verbunden sind oder aufgrund mehrerer Schutzschichten über WordPress Fehler zurückgeben). Ich weiß nur nicht, ob die Routen, die ich aufgelistet habe, richtig sind oder ob ich danach etwas übersehe.

Ich freue mich sehr über Ihre Antwort, dieses Thema ist derzeit ein großer Rückschlag für mein Projekt und ich freue mich, dass Sie sich weiterhin mit diesem Thema beschäftigen. Vielen Dank!

Habe das gleiche Problem mit über 400 benutzerdefinierten Posts mit acf-Feldern und 4000 Bildern.

Ich habe ein Update bekommen und konnte mit 35 Minuten bauen

Kann nicht erneut erstellt werden, nachdem ich got aktualisiert habe

Wie erwartet, da dieser Fehler immer noch in gatsby-wordpress existiert. 35 Minuten zum Herunterladen und Verarbeiten aller Bilder sind unter Berücksichtigung aller Faktoren (durchschnittliche Internetgeschwindigkeit, Verarbeitungsleistung, Gesamtzahl der Dateien usw.) eine sehr lange Zeit.
Sie können versuchen, die @njmyers- Version an Ihre spezifische Verwendung anzupassen. Es funktioniert wie ein Zauber, wenn Sie jede Bilddatei herunterladen, die Sie haben.

Wie erwartet, da dieser Fehler immer noch in gatsby-wordpress existiert. 35 Minuten zum Herunterladen und Verarbeiten aller Bilder sind unter Berücksichtigung aller Faktoren (durchschnittliche Internetgeschwindigkeit, Verarbeitungsleistung, Gesamtzahl der Dateien usw.) eine sehr lange Zeit.
Sie können versuchen, die @njmyers- Version an Ihre spezifische Verwendung anzupassen. Es funktioniert wie ein Zauber, wenn Sie jede Bilddatei herunterladen, die Sie haben.

Meine Site funktionierte gut, als ich eine kleine Anzahl von Bildern hatte, aber als ich anfing, mehr hinzuzufügen, passierte dies auch.

@MWalid wie kann ich das got aktualisieren? Danke.

versuche den ganzen Tag ohne Erfolg zu bauen. haben rund 1450 Bilder.

Wir können jetzt seit 2 Tagen nicht bereitstellen. Kann mir jemand helfen, mich in die richtige Richtung zu weisen, wo dies im Code auftritt, damit ich versuchen kann, eine Lösung zu finden?

Wir können jetzt seit 2 Tagen nicht bereitstellen. Kann mir jemand helfen, mich in die richtige Richtung zu weisen, wo dies im Code auftritt, damit ich versuchen kann, eine Lösung zu finden?

Haben Sie Ihre verschachtelte got Abhängigkeit von gatsby-source-filesystem aktualisiert, um mindestens Version 9.4.0 ?

Wenn nicht, sollten Sie Folgendes hinzufügen:

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

im package.json Ihres Gatsby-Projekts. Entfernen Sie dann node_modules und Ihre yarn.lock Datei und installieren Sie sie erneut.

Hinweis: Diese resolutions Funktion funktioniert nur für yarn . npm hat dies noch nicht implementiert.

@anagstef vielen Dank für den Tipp! Ich werde das versuchen und berichten.

Gibt es beim Ausführen von gatsby develop eine Möglichkeit, den lokalen Cache beizubehalten, anstatt jedes Mal entfernte Daten abzurufen, wenn der Befehl gestartet wird?

@anagstef scheint viel besser zu funktionieren! Danke für den Tipp!

Die Ausgabe ist beim Erstellen mit dieser Version von got sehr ausführlich. Weißt du, ob es eine Möglichkeit gibt, dies zu entfernen?

@nratter freut mich, dass es bei dir

Ja, das weiß ich, es ist sehr ausführlich und kann nicht ausgeschaltet werden. Ruiniert alle nützlichen Konsolenausgaben.

Nach einigen Untersuchungen, die ich durchgeführt habe, denke ich, dass es hier verursacht wird:
https://github.com/gatsbyjs/gatsby/blob/80c7023a8bc23886939205fe52e305277294e6af/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L155

Wie Sie sehen können, ruft es jedes Mal ein console.log mit dem Fortschritt des Downloads jeder Datei auf, wenn das downloadProgress Ereignis ausgegeben wird, was zu oft pro Sekunde passiert. Dies war vorher kein Problem, da die alte got Version das downloadProgress Ereignis nicht implementiert.

Vielleicht können wir das mit einer PR beheben? Sieht aus wie das Debuggen von übrig gebliebenen Code.

Ich hatte das gleiche Problem und blieb bei "Quell- und Transformationsknoten" hängen. Nach vielen console.logs bestand mein Problem darin, dass beim Abrufen von Mediendateien aus WordPress Zeitüberschreitungen aufgetreten sind. Das Problem war nicht, dass der Server damit nicht umgehen konnte, sondern eher die Begrenzung der Cloudflare-Rate und das Auslösen von Timeouts nach etwa 350 Anfragen.

Ich habe Cloudflare umgangen, bin direkt zu den vps gegangen und sehe keine "Quell- und Transformationsknoten mehr" und mein Build ist abgeschlossen.

Meine Problemumgehung bestand darin, ein lokales WordPress zum Testen zu verwenden, die Live-Site befindet sich in Netlify, während die Bereitstellung keine Probleme verursachte.

Leute, ich habe es geschafft, dies zu beheben, indem ich createRemoteFileNode Anfragen seriell statt parallel ausgeführt habe.

Hier ist die Funktion, die ich verwende:

/**
 * 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
}

und so verwende ich es:

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

Nachdem die Bilder heruntergeladen wurden, sieht mein Quell- und Transformationsschritt so aus

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

Hoffe es löst auch deine Probleme.
Beifall

@ancachoria wo soll ich diesen Code einfügen?

@ancachoria ja, mir ist auch unklar, wo ich diesen Code platzieren soll.

Dies hat etwas nichts mit dem gatsby-source-wordpress Plugin zu tun. Ich habe den obigen Code in meinem gatsby-node.js . Die Idee ist, dass das gleichzeitige Auslösen all dieser Anfragen zum Scheitern führt, also habe ich diese Hilfsfunktion geschrieben, um sie nacheinander auszulösen.

Ich vermute, dass es in gatsby-source-wordpress auch ein ähnliches Problem gibt, aber ich bin damit nicht so vertraut.
Tut mir leid, dass ich nicht mehr helfen kann.

Es scheint mit massiven Bildern und langsamen Internetverbindungen zusammenzuhängen. Netlify konnte die Site erstellen, aber meine lokale Verbindung war nicht, da es nur 1 MB / s Download ist, was dazu führte, dass es nach 30 s zu einer Zeitüberschreitung und einem Fehler beim großen Bild kam.

Ich habe 1 GB Glasfaser und keine "massiven" Bilder.

Ich transformiere Blog-Bilder nicht lokal, nachdem ich sie WordPress heruntergeladen habe, ich verwende einfach ihre URL. Es wäre schön, wenn es eine Einstellung gäbe, die das Herunterladen dieser Bilder in diesem Fall deaktiviert.

Leute, ich habe es geschafft, dies zu beheben, indem ich createRemoteFileNode-Anforderungen seriell statt parallel ausgeführt habe.

Ja, das Problem basiert wirklich auf der Tatsache, dass createRemoteFileNode eine Parallelität von 200 verwendet, was für die meisten WP-Server zu viel ist. Ich habe meine Bilder auf CloudFront und habe dort einige Ratenlimits erreicht.

Ich habe eine Weile versucht, das Problem mit einer verzweigten Version des Quell-Plugins zu beheben, aber das Problem liegt wirklich nicht in gatsby-source-wordpress sondern in gatsby-source-filesystem . Im Idealfall könnten Verbraucher der Funktion createRemoteFileNode dort die Parallelität übergeben. Dann könnten Plugins die Parallelitätsoption in ihren Konfigurationen verfügbar machen. Ich würde immer noch gerne eine PR machen, um dieses Problem anzugehen!

Die Lösung, die ich verwendet habe, ist nur ein einfaches Skript, um den Code in node_modules zu ändern. Wirklich ziemlich zerbrechlich und nicht ideal, aber es ist ein einfacher Hack, um die Parallelität direkt zu ändern. Verwendet shelljs also soll es auch für Windows-Benutzer funktionieren (habe es nicht versucht).

#!/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);

Ich hatte das gleiche Problem und blieb bei "Quell- und Transformationsknoten" hängen. Nach vielen console.logs bestand mein Problem darin, dass beim Abrufen von Mediendateien aus WordPress Zeitüberschreitungen aufgetreten sind. Das Problem war nicht, dass der Server damit nicht umgehen konnte, sondern eher die Begrenzung der Cloudflare-Rate und das Auslösen von Timeouts nach etwa 350 Anfragen.

Ich habe Cloudflare umgangen, bin direkt zu den vps gegangen und sehe keine "Quell- und Transformationsknoten mehr" und mein Build ist abgeschlossen.

genau das war mein problem. Netlify baute sehr schnell - weniger als 2 Minuten. Nur etwa 30 Beiträge mit etwa 500 Quellbildern. Lokal war nicht alles abgeschlossen, einfach das Deaktivieren des CloudFlare-Status auf DNS löste das Problem nur sofort

Ich hatte das gleiche Problem und blieb bei "Quell- und Transformationsknoten" hängen. Nach vielen console.logs bestand mein Problem darin, dass beim Abrufen von Mediendateien aus WordPress Zeitüberschreitungen aufgetreten sind. Das Problem war nicht, dass der Server damit nicht umgehen konnte, sondern eher die Begrenzung der Cloudflare-Rate und das Auslösen von Timeouts nach etwa 350 Anfragen.
Ich habe Cloudflare umgangen, bin direkt zu den vps gegangen und sehe keine "Quell- und Transformationsknoten mehr" und mein Build ist abgeschlossen.

genau das war mein problem. Netlify baute sehr schnell - weniger als 2 Minuten. Nur etwa 30 Beiträge mit etwa 500 Quellbildern. Lokal war nicht alles abgeschlossen, einfach das Deaktivieren des CloudFlare-Status auf DNS löste das Problem nur sofort

Ich habe auch festgestellt, dass dies der Fall ist. Ich hatte zuvor ein Image, das zum Fehlschlagen des Builds führte, und wies Cloudflare als das Problem zurück. Das Problem ist seitdem wieder aufgetreten und da leiten , wurde das Problem sofort auch lokal gelöst.

Wollte nur wiederholen, dass dies nicht nur ein WP-Quellproblem ist – ich hatte das gleiche Problem mit gatsby-source-prismic , die Reduzierung der Parallelität von soure-filesystem mit @njmyers Hack hat es für mich behoben Begrenzungs-/Überlastungsproblem.

Stimmen Sie zu, dass zumindest die Parallelität des Quelldateisystems konfigurierbar sein sollte.

@njmyers Es tut mir leid, das zu fragen, aber wie genau wird dieser Fix ausgeführt. Führen Sie das Skript einfach vor dem Build aus oder muss ich das Skript im Build-Prozess irgendwie referenzieren, weil ich mich gerade frage, wie ich diesen Fix lokal und beispielsweise auch auf netlify anwende.

@alexanderwe Keine Sorge, es ist sowieso ein dummer Hack. Sie können es ausführen, nachdem Sie node_modules installiert haben. Ich bin mir nicht 100% sicher, aber ich glaube, dass postinstall in Ihrer Projektdatei package.json funktionieren würde.

Für mich hängt Gatsby 50% der Zeit an "Quell- und Transformationsknoten", wenn ich Json mit mehr als 500 enthaltenen Bildern verwende. Ich verwende gatsby-source-custom-api

Bilder werden auf einem schnellen, stabilen Server gehostet.
Meine Internetverbindung ist auch schnell und stabil.

"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",

Was kann ich tun, um das zu debuggen?

Dieses Problem tritt nur bei gatsby-source-custom-api oder source-wordpress auf.

Mir passiert es auch. Ich habe jede vorgeschlagene Lösung ausprobiert und nichts scheint zu funktionieren. Ich werde Wordpress definitiv nicht mehr als Backend für Gatsby verwenden, obwohl ich höre, dass Leute ähnliche Probleme mit anderen Diensten haben.

@alexanderwe Der richtige Weg, dies zu beheben, besteht darin, den von @njmyers vorgeschlagenen Patch zu implementieren
Dann stellen Sie gatsby-source-wordpress und anderen einen weiteren PR vor, um dies anhand ihrer Referenz in gatsby-config.js tatsächlich konfigurierbar zu machen

@sebastienfi Ich bin gerade über dieses https://github.com/gatsbyjs/gatsby/issues/14819#event -2418874313 und den entsprechenden Commit https://github.com/gatsbyjs/gatsby/commit/90aa24787b32ef9613b6becbfadab6029ec39-18649edbdiff2263 fügt eine Umgebungsvariable hinzu, um die Parallelitätsrate zu konfigurieren, wodurch das Problem für mich gelöst wurde. Es gibt auch eine anhaltende Diskussion über Umgebungsvariablen im Vergleich zu Konfigurationsparametern: https://github.com/gatsbyjs/gatsby/issues/14636

Haben Sie versucht, GATSBY_CONCURRENT_DOWNLOAD auf eine niedrigere Zahl einzustellen? Standardmäßig ist es auf 200 eingestellt.

Linux/Mac:
GATSBY_CONCURRENT_DOWNLOAD=5 gatsby build

Fenster:
setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build

@wardpeet
Ich habe es versucht, es hat sich nichts geändert

Es hat definitiv etwas mit dem Quelldateisystem zu tun, da die Protokolle zeigen, dass die Bilder erfolgreich abgerufen wurden... Lösung dafür...

Nachdem ich das WordPress-Quell-Plugin auf Debug gesetzt habe, sehe ich dies

legt immer zwischen 470-480 auf... aber normalerweise nicht an der gleichen Stelle.

Weiß jemand wo im Code das ausgeführt wird?

Ich habe es schließlich zum Laufen gebracht, indem ich ein VPN auf halbem Weg umgeschaltet habe

Ist jemand bereit, mir sein Repo und seine Anmeldeinformationen mitzuteilen, damit ich es ausprobieren und versuchen kann, das Problem zu finden?

Schreib mir [email protected]

mein Repository ist zu diesem Zeitpunkt nicht einfach neu zu erstellen – ich habe ein Backup der DB, wie es irgendwo war, aber um die Site zu erstellen, musste ich jeden Monat Beiträge in einen einzigen Beitrag für jahrelangen Inhalt reduzieren.

@wardpeet hat dir meinen Repo Ward ([email protected]) per E-Mail geschickt. lass mich wissen wie es geht.

Unsere Firma hat das WLAN geändert und die Bandbreite erhöht. Heute hatte ich keine Probleme beim Herunterladen der Bilder.... Aber ich verstehe immer noch nicht, ist das Netzwerk oder die Parallelität?

jedoch schlagen alle Builds auf Netlify fehl ...

17:13:43 Uhr: === [Wordpress__wp_media wird abgerufen] === https://wildkiwi.com/wp-json/wp/v2/media
17:13:43 Uhr: Gesamtheit der Einheiten: 1717
17:13:43 Uhr: Anzufordernde Seiten: 344
17:13:45 Uhr: Die Anfrage ist mit Fehlercode "undefiniert" fehlgeschlagen

Fehlercode ist nicht definiert, daher verstehe ich nicht wirklich, was passiert...

Wenn ich die gleichzeitigen Anforderungen auf 5 ändere, funktioniert es auf Netlify

Ich hatte dieses Problem mit einem anderen Plugin (https://github.com/angeloashmore/gatsby-source-prismic) und die Einstellung von GATSBY_CONCURRENT_DOWNLOAD=50 hat den Zweck erfüllt.

Dies geschah einfach aus heiterem Himmel (an einem Tag wurde meine Site erstellt, am nächsten nicht, ohne Änderungen), und ohne jede Art von Fehlermeldung ist es ein wenig beunruhigend, Websites für Kunden bereitzustellen, ohne davon überzeugt zu sein wird nicht wieder vorkommen.

Wir laden grundsätzlich 200 Bilder auf einmal herunter, aber dies kann für einige Computer/Internetverbindungen problematisch sein. Eine gute Lösung besteht darin, einige Wiederholungsmechanismen zu backen.

Ich hatte diese Probleme, aber es gelang mir, den Build mit einer Kombination aus setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build und Smushing aller Bilder (von denen einige übermäßig groß und Dateigröße waren) mit der kostenlosen Version von https:// gut zum Laufen zu bringen.

Hallo! Ich habe das gleiche Problem mit einem von mir erstellten Quell-Plugin (ohne Bezug zu WordPress) und beim Herunterladen von mehr als 1000 Bildern von einer API. Es hängt fast immer am Ende des Prozesses.

Das Einstellen von GATSBY_CONCURRENT_DOWNLOAD Problem nicht gelöst. Ich habe es mit 50 , 20 , 5 versucht, kein Glück.

Ich bekomme eine Sammlung von Größen von der API, und ich habe das größte Bild verwendet, es aber in das kleinste geändert und auch nicht repariert.

Es ist schwer zu erkennen, warum es an dieser Stelle fehlschlägt, das einzige, was ich bekomme, ist source and transform nodes und dann für immer Stille.

Es wäre toll, dafür einen Debugging-Mechanismus zu haben.

Ich hatte das gleiche Problem bei einer Gatsby+Wordress-Integration. Der Build würde in der onCreateNode-API, in der ich createRemoteFileNode verwendet habe, für immer anhalten.

Lösung: Ich habe das gatsby-source-filesystem von 2.0.4 auf 2.1.8 aktualisiert und GATSBY_CONCURRENT_DOWNLOAD=50 zu meinen Umgebungsvariablen hinzugefügt.

Hallo

ich habe ein ähnliches Problem bei meinem Projekt.

Umfeld

  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

Ich habe mehr als 80000 Medien auf meiner WP-Site. Wenn ich npx gatsby develop ausführe, stecke ich nach "END PLUGIN" fest.

...
=== [ 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

Ich habe versucht, den Wert GATSBY_CONCURRENT_DOWNLOAD zu ändern, aber es hat sich nichts geändert.
Gibt es eine Möglichkeit den Medienmengenimport zu begrenzen? Beispielsweise :

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

Das gleiche Problem hier, mein selbst gehostetes WP hat 1690-Medien, ich stecke immer am Ende des Schrittes Remote-Dateien herunterladen fest, manchmal fehlt nur ein Medium ...

Bearbeiten: Dieses Mal war der Build mit GATSBY_CONCURRENT_DOWNLOAD=5 yarn build ...

@kvalium Danke für deinen Kommentar, GATSBY_CONCURRENT_DOWNLOAD=5 yarn build hat bei mir funktioniert

Ich hatte das gleiche Problem und kann es lösen, indem ich die Größe des Terminalfensters verändere.

Bitte beachten Sie die letzten Kommentare zu #4666.

Das gleiche Problem hatte ich auch. Ich habe es gelöst mit:

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

Hoffe es kann helfen

Scheint ein skurriles Thema zu sein. Hier meine Erfahrung damit:

• ❌ Ich habe dieses Problem auf macOS High Sierra (mit iTerm) gesehen.
• ✅ Ich habe angefangen, GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop und das Problem ging weg (dies war ein paar Wochen lang der Fall)
• ❌ Ich habe auf Mojave aktualisiert und meine globale Gatsby-Installation auf 2.7.47 aktualisiert und dann das Problem wieder gesehen (mit iTerm)
• ❌ Habe versucht, GATSBY_CONCURRENT_DOWNLOAD in 5 zu ändern
• ❌ Versuchte .cache und node_modules wegzublasen
• ❌ Ich habe versucht, die Größe des iTerm-Fensters zu ändern, während gatsby develop (beide mit 50 und 5)
• ❌ GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop in der App "Terminal" ausgeführt, nicht in iTerm
• ✅ Zwei Wochen später habe ich versucht, GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop in iTerm zu verwenden und die Größe des Fensters während des Vorgangs ein paar Mal geändert, und es hat funktioniert.

Dachte zu früh, dass ich es mit dem letzten laufen würde, aber dann hing es. Hoffentlich hilft das anderen. Es sieht immer noch so aus, als ob das noch nicht ganz festgenagelt ist, aber wir kommen langsam aber sicher dorthin.

Update: Heute hat das bei mir funktioniert. Ich bin mir nicht sicher, ob es daran liegt, dass ich das iTerm-Fenster zum richtigen Zeitpunkt im Prozess verkleinert habe oder weil ich beobachtet habe, wie es von 93% auf 100% gestiegen ist, aber diesmal war etwas anders.

Um GATSBY_CONCURRENT_DOWNLOAD = 5 zu verwenden, fügen Sie den folgenden Code in Ihre Datei gatsby-node.js ein

// Internationalisierung
exports.onPostBuild = () => {
ChildProcess.execSync("ps aux | grep jest | grep -v grep | awk '{print $2}' | xargs kill")
console.log('Gebietsschemas werden kopiert')
fs.copySync(path.join(__dirname, '/src/locales'), path.join(__dirname, '/public/locales))
}

532314892 @bradydowling :

Ich bin mir nicht sicher, ob es daran liegt, dass ich das iTerm-Fenster an der richtigen Stelle verkleinert habe

Während ich das gleiche Problem hatte, habe ich die Größe meines iTerm-Fensters und -Bams geändert – es ging auch plötzlich weiter. Ich weiß nicht, ob das ein wilder Zufall ist oder...

@bradydowling @davegregg Woah das ist bizarr. Die Größenänderung meines iTerm-Fensters hat den Zweck erfüllt.

@ TylerBarnes Was auch immer das ist, ich würde vorschlagen, dass es nicht WordPress-spezifisch ist. Ich benutze nichts, was mit WordPress zu tun hat.

@beauhankins Und du?

@davegregg @beauhankins @bradydowling kann jemand von euch ein Repo teilen, in dem dies geschieht? Das scheint wirklich bizarr, dass das Ändern der Größe Ihres Terminalfensters das Problem behebt.

@ TylerBarnes ya hier ist ein Repo, wo ich es gesehen habe. Ich habe es ein bisschen nicht angerührt.

Randnotiz: Wie gehen Sie mit einer Situation um, in der Sie eine Gatsby-Site mit einer älteren Version von Gatsby klonen als die, die derzeit von der CLI installiert ist?

Ich habe die Befehle mit dem VS-Code-Terminal ausgeführt (ich verwende Bash). Es hat ewig gedauert und wie oben vorgeschlagen habe ich den Vollbildmodus verlassen und es hat funktioniert.

@bradydowling danke für das teilen deines Repositorys! Um ältere Versionen von Gatsby als cli zu verwenden, können Sie ein npm-Skript zum Entwickeln und Erstellen erstellen.

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

Wenn Sie dann npm run develop oder yarn develop ausführen, wird die lokale Version in Ihrem Projekt verwendet.

Wir untersuchen dieses Problem, aber in der Zwischenzeit kann jeder, der das Problem hat, es möglicherweise umgehen, indem er CI=1 yarn build , da dies eine andere Reporterbibliothek im Hintergrund verwenden sollte. Wenn Sie das versuchen und es funktioniert, lassen Sie es uns bitte wissen!

@dustinhorton :

v2-Version @ https://github.com/dustinhorton/gatsby-v2-issue. Baue zu diesem Zeitpunkt etwa 50 Minuten.

Fww. Mir ist klar, dass das vor etwa einem Jahr gepostet wurde und Gatsby sich seitdem erheblich verändert hat. Wenn ich es auf meinem Computer ausführe (und die Gatsby-Version in package.json auf * setze), scheint der Build in etwa 2000 Sekunden (~33 Minuten) abgeschlossen zu sein.
Außerdem gibt es beim Upgrade der cli jetzt einen Fortschrittsbalken, der einen großen Unterschied in Bezug auf die "Anfühlung" ausmacht, da Sie eine konkretere Feedbackschleife erhalten.

Der Beschaffungsschritt dauert fast die ganze Zeit (1968 / 1975 Sekunden). Das Herunterladen von Remote-Dateien ist das meiste davon (1845 Sekunden).

Das überrascht mich nicht, wenn ich mir einen einzelnen Roundtrip zu diesem Server anschaue:

# 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

Jede Anfrage dauert ungefähr 2 bis 4 Sekunden. Die 75 Seiten, die beim Erkunden zunächst abgerufen werden, dauern insgesamt 18 Sekunden (!). Ich habe eine schnelle Verbindung und kann dieses Timing mit einem einfachen Wget reproduzieren.

Der längste Schritt wird also versuchen, etwa 7500 Ressourcen herunterzuladen. Wenn man bedenkt, dass eine einzelne Anfrage 2 bis 4 Sekunden dauert, überrascht es mich nicht, dass es so lange dauert.

Trotzdem bemerke ich einige Pausen während des Hauptdownloads von 1845 Sekunden. Ich bin mir nicht sicher, ob dies nur der Server ist, der die Daten drosselt oder nicht (ich habe die Parallelität auf 5 gesetzt).

Ich habe versucht, mit der Breite des Terminals zu wackeln (ich bin auf xfce linux, fwiw) und obwohl dies gelegentlich mit dem Fortschritt zusammenfiel, bin ich jetzt davon überzeugt, dass dies eher ein Zufall als eine Kausalität ist.

Fazit: Während ich den langsamen Download und den scheinbar "steckengebliebenen" Fortschritt reproduzieren kann, deuten derzeit alle Anzeichen darauf hin, dass dies so ziemlich durch das Warten auf die Serverantwort verursacht wird. Darüber hinaus scheint die Breite des Terminals dies nicht zu beeinflussen.

Allerdings: Es _ist_ möglich, dass die Terminalausgabe beim Aktualisieren des Fortschrittsbalkens auf eine ganz bestimmte Breite irgendwie hängenbleibt. Dies ist zwar unwahrscheinlich, aber nicht unmöglich. Daher brauchen wir wirklich ein Repro, das wir selbst ausführen können (also keine Authentifizierung). Und vorzugsweise einen, der _nicht_ von einem Remote-Server abhängt, da ich den Server nicht hämmern möchte.

Ich werde die Labels zu diesem Thema entsprechend aktualisieren.

Das Repro, das in https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -438667221 von @njmyers gepostet wurde, existiert nicht mehr

Das in https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -562607399 von @bradydowling gepostete Repo erfordert eine Reihe von Berechtigungen, die ich nicht habe, und scheint ähnliche Probleme mit der Rundreisezeit zu haben

@ 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

Dieser Sourcing-Schritt zeigt nicht wirklich irgendeinen Fortschrittsindikator an, außer dem Spinner und gelegentlich werden Schritte protokolliert, und dauert immer noch ein paar Minuten, also können wir vielleicht zumindest eine Art Fortschrittsindikator anzeigen, wenn das Sinn macht.

Außerdem könnte es vielleicht hilfreich sein, auf die durchschnittliche Zeit zum Abrufen einer Ressource hinzuweisen, da dies ein Hinweis darauf ist, warum "Gatsby" langsam ist, obwohl dies tatsächlich durch die Hin- und Rückfahrt verursacht wird.

In diesem Repo dauerte sogar das Herunterladen von 589 Remote-Dateien etwa 5 Minuten, wobei der Fortschrittsbalken oft ohne ersichtlichen Grund hängen blieb.

Nach dem Bootstrap schlägt der Build bei mir fehl, da Dateien fehlen.

@pvdz Ich muss noch einmal damit spielen (ich habe es für eine Weile aufgegeben), aber es gibt bestimmte Dateien, die Berechtigungsprobleme verursachen, selbst wenn es erfolgreich erstellt wird, also dachte ich, dass diese ignoriert werden können.

Aber um Ihren Beitrag zusammenzufassen, sagen Sie, dass bestimmte (Download-)Schritte einfach sehr lange dauern und wir länger warten sollten, bis sie abgeschlossen sind?

@bradydowling Nun, sieht so aus, ja. :)

FTR: Ich habe das Sammeln von Ressourcen ein wenig verfolgt. Um etwas Licht ins Timing zu bringen;

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

Dies sind übrigens 6 MB-Dateien. Ich habe eine 250-Mbit/s-Verbindung, die für schnellere Verbindungen als 1 MB geeignet ist, aber es überrascht mich nicht, dass die Download-Zeiten in die Höhe getrieben werden. Keine noch so große Größenänderung wird das beschleunigen ;)

Interessant. Dies ist nur ein standardmäßiger persönlicher WordPress-Blog, der auf EC2 gehostet wird, also ist es keine riesige Installation. Vielleicht liegt das daran, dass all diese Anfragen den Host überlasten. Oder ich bin kein WordPress-Experte, aber vielleicht gibt es eine Art Standard-WP-Ratenlimit für REST-API-Aufrufe, die passieren können? Ich gehe auch davon aus, dass dieses Verhalten nicht nur auf dieser Site auftritt.

Vielleicht liegt das daran, dass all diese Anfragen den Host überlasten.

Dies ist meine Vermutung (oder etwas in diesem Baseballstadion). Aber ich untersuche ein bisschen unsere eigene Architektur, um zu überprüfen, ob wir durch Abstraktionen an Effizienz verlieren. Aber wenn man bedenkt, dass ich die meiste Zeit mit einfachen Wgets / Locken nachahmen kann, bezweifle ich, dass da viel drin ist.

Also fwiw habe ich die got.stream() Bits durch einen dummen Raw-Downloader ersetzt:

    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

Also ja, ich bin mir ziemlich sicher, dass die langen Verzögerungen (zumindest in diesem Fall) durch den Download verursacht werden. Daher ist es vielleicht am besten, das Feedback zu verbessern, während wir auf einen Download warten :)

Viele, viele Leute sagen, dass die Größenänderung von Terminalfenstern (aus irgendeinem seltsamen Grund) den Entwicklungsprozess auflöst, der auf 'Quell- und Transformationsknoten' stecken geblieben ist.

Leider ist dies bei der Verwendung von WSL keine Lösung. Stecken Sie sowohl beim Build als auch beim Entwickeln lokal mit 'Quell- und Transformationsknoten' fest. Netlify-Builds funktionieren, aber lokale Entwicklung ist unmöglich geworden.

@Vacilando können Sie einige Links, die während des Sourcings für Ihre Site heruntergeladen werden, debuggen und manuell testen, ob sie schnell heruntergeladen werden? Wie ich oben erwähnt habe, ist ein großes Problem, das ich sehe, dass bestimmte wp-Hosts einfach super langsam sind.

Wenn der Host also langsam ist und viele Inhalte heruntergeladen werden müssen, dann wird dieser Schritt viel Zeit in Anspruch nehmen, denn das ist alles, was er in diesem Schritt tun sollte. Inhalte entdecken und herunterladen :)

Wenn Sie bestätigt haben, dass der Inhalt selbst in einem Bruchteil des gesamten Schrittes heruntergeladen wurde, kreisen Sie bitte hier zurück. In diesem Fall wäre ein Repro enorm hilfreich :)

Vielleicht könntest du in einer idealen Welt eine Flagge an Gatsby übergeben, die zwischenspeichern würde
den Site-Asset-Download, damit dies nicht wiederholt werden muss.

Eine andere optimale Lösung wäre, ein Flag zuzulassen, das eine Art von . setzt
Ratenbegrenzung oder Drosselung beim Herunterladen von Assets, damit es nicht kaputt geht
der Gastgeber.

Irgendwelche Gedanken zu diesen beiden Ideen?

Am Do, 19.12.2019, 18:09 Uhr Peter van der Zee [email protected]
schrieb:

@Vacilando https://github.com/Vacilando können Sie einige Links debuggen, die ?
werden während des Sourcings für Ihre Site heruntergeladen und manuell getestet
ob sie schnell herunterladen? Wie ich oben erwähnt habe, habe ich ein großes Problem
zu sehen ist, dass bestimmte wp-hosts einfach super duper langsam sind.

Wenn der Host also langsam ist und viele Inhalte heruntergeladen werden müssen, dann ja
Dieser Schritt wird viel Zeit in Anspruch nehmen, denn das ist alles, was es tun sollte
dieser Schritt; Inhalte entdecken und herunterladen :)

Wenn Sie bestätigt haben, dass der Inhalt selbst in einem Bruchteil der Zeit heruntergeladen wird
ganzen Schritt, kreisen Sie bitte hier zurück. In diesem Fall wäre ein Repro
enorm hilfreich :)

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/gatsbyjs/gatsby/issues/6654?email_source=notifications&email_token=ABS4AU62367MTEWP7LJXWTLQZP5L5A5CNFSM4FLHT3T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN17
oder abmelden
https://github.com/notifications/unsubscribe-auth/ABS4AU7GCV4YMZQH6R37BSDQZP5L5ANCNFSM4FLHT3TQ
.

@bradydowling Ein Teil davon existiert bereits. Sie können eine Umgebungsvariable GATSBY_CONCURRENT_DOWNLOAD festlegen, um das Limit für gleichzeitige Anforderungen zu konfigurieren. Die nächste Hauptversion von gatsby-source-wordpress https://github.com/gatsbyjs/gatsby/issues/19292 wird mehr Kontrolle darüber haben, wie Mediendateien heruntergeladen werden. Was das Caching angeht, werden heruntergeladene Dateien derzeit zwischengespeichert, aber wenn Sie eine gatsby-*.js-Datei ändern, wird der Cache derzeit gelöscht, um zu verhindern, dass ein veralteter Cache unerwartete Fehler verursacht. Das ist also eher ein Kernproblem als gatsby-source-wordpress spezifisch, aber es wird ständig daran gearbeitet, den Cache von Gatsby zu verbessern.

Teilweise sollte Jobs Api (#19831) dieses Caching-Problem beheben.

Ja, ich sah das Stück ungefähr GATSBY_CONCURRENT_DOWNLOAD näher an der Spitze. Aus meiner Erfahrung hat das nicht geholfen, also war mein Vorschlag wohl eine feinkörnigere Steuerung wie in mb pro s/m/h oder so ähnlich. Vielleicht sage ich nur Unsinn.

@bradydowling Ich betrachte das Hinzufügen von Anforderungswiederholungen mit exponentiellem Backoff sowie das Hinzufügen einer optionalen Einstellung für maximale Anforderungen pro Sekunde für Fälle, in denen dies nicht gut genug funktioniert.

Hallo!

Dieses Thema ist ruhig geworden. Gruselige Stille. 👻

Wir bekommen viele Probleme, daher schließen wir Probleme derzeit nach 30 Tagen Inaktivität. Das letzte Update hier ist mindestens 20 Tage her.
Wenn wir dieses Problem verpasst haben oder Sie es offen halten möchten, antworten Sie bitte hier. Sie können auch das Etikett "nicht veraltet" hinzufügen, um dieses Problem offen zu halten!
Als freundliche Erinnerung: Der beste Weg, dieses oder jedes andere Problem zu beheben, besteht darin, einen Pull Request zu öffnen. Unter gatsby.dev/contribute finden Sie weitere Informationen zum Öffnen von PRs, zur Prüfung von Problemen und zum Beitragen!

Danke, dass Sie ein Teil der Gatsby-Community sind! 💪💜

Ich werde das jetzt schließen.

Wenn Sie glauben, dass Sie ein Problem mit der WordPress-Beschaffung haben, vergewissern Sie sich bitte zuerst, dass Ihre Verzögerungen nicht durch einen langsamen WordPress-Server verursacht werden. Dann öffnen Sie bitte eine _neue_ Ausgabe (Sie können aber auch gerne auf diese Ausgabe verweisen).

Die hohe Anzahl an Kommentaren macht es sehr schwierig, die Diskussion zu verfolgen. Das Öffnen einer neuen Ausgabe führt also eher dazu, dass Ihr spezifisches Problem eine Antwort erhält.

Ich und andere haben es in den letzten anderthalb Jahren bestätigt. Mein ursprüngliches Problem war auf einem gut abgestimmten vps. @njmyers hatte eine wahrscheinliche Lösung oder zumindest eine Verbesserung, konnte jedoch keine Antworten von den Betreuern erhalten, wie sie es gerne hätten.

Ich dachte darüber nach, mich selbst zu schließen, aber ich denke, es muss als Warnung da draußen sein, dass eine mäßig große WordPress-Site noch nicht gut zu Gatsby passt.

@dustinhorton Das verstehe ich. Diese Ausgabe ist über eineinhalb Jahre alt, die Dinge ändern sich schnell. Bei so vielen Kommentaren ist es schwierig, das eigentliche Problem zu erkennen.

Fwiw, wie oben erwähnt, habe ich die zuletzt gemeldeten Repros überprüft und festgestellt, dass diese zumindest durch langsame Fernbedienungen verursacht wurden. Wenn Sie ein Repro mit einem aktuellen Gatsby-Release auf einer schnellen Fernbedienung haben, lassen Sie es mich bitte wissen, auch wenn es vielleicht schon in diesem Thread gepostet wurde. Oder öffne vielleicht eine neue Ausgabe dafür (und markiere mich), wenn du dich mehr darauf konzentrieren möchtest, das überlasse ich dir :)

(_Nur um es klarzustellen, wir haben dieses Problem geschlossen, weil es mit zu vielen Off-Topic-Nachrichten etwas veraltet ist. Bitte haben Sie nicht das Gefühl, dass wir die Diskussion unterdrücken, da dies nicht die Absicht ist und wir erkennen, dass unsere Arbeit hier noch nicht abgeschlossen ist !_)