Можете ли вы подготовить репо репо с репродукцией? Количество сообщений не должно быть проблемой (по крайней мере, на этом этапе) - v1 может вызвать проблемы с памятью, но это будет на более позднем этапе сборки и не должно застревать

Было любопытно, была ли это проблема с Local by Flywheel и возможность создания сайта при обслуживании WordPress через 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 минут. Жестоко, но также интересно, что это всего на 3 минуты дольше для ~ 9000 предметов. Он уже давно сидит на ⠁ run graphql queries .

edit: это длилось 419,470 с, или 7 минут.

@pieh Упс, опубликовал это до того, как увидел, что ты только что ответил. Я могу попробовать запустить этот сайт удаленно завтра.

И эта последняя строка, предназначенная для включения, находится там, где она висит через Local и занимает вечность через 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, это занимает несколько часов), но это определенно выявляет проблему: https://github.com/dustinhorton/gatsby-issue

Должен быть в состоянии просто клонировать это и строить.

Просто запускался дважды в течение более 10 часов без завершения строительства сайта. Пожалуйста, дайте мне знать, что еще я могу предоставить для помощи в отладке.

Не могли бы вы попробовать перейти на v2? Мы внесли массу улучшений в скорость различных подсистем gatsby, которые должны значительно ускорить работу таких больших сайтов.

@KyleAMathews Я

@KyleAMathews v2 version @ https://github.com/dustinhorton/gatsby-v2-issue. К этому моменту строили около 50 минут.

Убить это сейчас. Сайт еще не построен.

Еще вы можете попробовать включить трассировку https://next.gatsbyjs.org/docs/performance-tracing/.

Мы еще не добавили поддержку трассировки в gatsby-source-wordpress, но отчеты о трассировке могут помочь вам выяснить, где она застопорилась.

Если кто-то еще заинтересован в этом, отличным пиаром будет добавление поддержки трассировки в gatsby-source-wordpress. Дай мне знать, если тебе интересно!

К сожалению, мне придется от этого избавиться, так как мне нужно тратить все время, которое у меня есть на перенос на традиционную тему, - что-то вроде подавленного из-за того, что не могу использовать Gatsby. Все остальное кажется таким отсталым.

Извините, у нас не было возможности разобраться в этом :-( Спринт прямо сейчас, чтобы выпустить v2.

Есть ли шанс, что вы можете оставить сайт WP работающим? Определенно кажется, что здесь есть ошибка, которую нужно исправить.

Я написал в Твиттере с просьбой о помощи, так что надеюсь, что кто-то скоро воспользуется этим :-)

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

Вау, это круто - большое спасибо. Сайт пока никуда не денется (и я перенесу копию и обновлю репозиторий репродукций, если это необходимо).

@dustinhorton, чего стоит. Я также заметил проблемы при создании более крупного (~ 1000 сообщений) проекта на Local by Flywheel по сравнению с нашей производственной средой с CDN перед ним.

Ответы REST для Gatsby в 10-20 раз длиннее от Local, чем от production, поэтому создание сайта занимает целую вечность. Я еще не тратил время на отладку проблемы в Local, но она в моем списке дел :)

@KyleAMathews Я мог бы взглянуть на добавление трассировки в source-wordpress.

@Khristophor , было бы здорово!

@dustinhorton Я вижу 404 для изображений на вашем образце сайта (например, https://dustinhorton.com/gatsby-wp/wp-content/uploads/2018/07/IMG_9906.jpg), которые могут раздуть сборку время. Есть ли шанс найти пути для них?

Запросы WP_MEDIA выполняются довольно быстро с результатами, поэтому я решил, что
ясно, но я могу взглянуть на это позже на этой неделе, если вы так считаете
может быть так.

В среду, 8 августа 2018 г., в 17:45 Крис Уайзман [email protected]
написал:

@dustinhorton https://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

Получение 404 на изображениях 7504 может вызвать некоторые проблемы;)

Поверьте, я вычистил все 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.

Это приличный VPS на Линоде. Я могу изменить настройки, если это поможет. Но проблема возникает и локально.

https://github.com/gatsbyjs/gatsby/blob/46290c2b0e7894fca036bdcc658a5d1936c4221f/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L133 -L159 иногда работает неправильно of files - сетевой запрос разрешен, но поток записи в файл никогда не завершается (или ошибки не завершаются). Я думаю, было бы здорово добавить какой-то тайм-аут после завершения responseStream чтобы дождаться завершения fsWriteStream , а если это не так, уничтожить все ресурсы и попытаться снова записать файл (возможно сделать несколько повторных попыток) и фактически выдает ошибки, когда на самом деле это невозможно.

@pieh, не могли бы вы прислать обновленный код для этого файла?

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

@ aman-developer для этого пока нет исправления - иначе оно было бы опубликовано. Проблема с этой проблемой в том, что нет надежного способа воспроизвести это, поэтому любые исправления являются предположениями. В некоторых случаях проблема заключается в том, что файловая система writeStream (может быть, зависит от оборудования и / или ОС) не завершается и застревает, не вызывая ошибок, поэтому любое исправление здесь действительно пытается решить проблемы в fs package / hardware / os ненадежный: /

Были ли у вас проблемы с воспроизведением моего репо и сайта? Для меня это стабильно.

Я использую createRemoteFileNode для получения удаленных изображений, и у меня такая же проблема: загрузка застревает на отметке 680/780 мб.

В createRemoteFileNode есть слушатель события downloadProgress который был добавлен в https://github.com/sindresorhus/got/releases/tag/v8.0.0, но gatsby-source-filesystem использует 7.1.0.

Я пробовал обновиться до последней версии 9.2.2 и теперь смог успешно загрузить все изображения.

Добавьте это в package.json:

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

Также, похоже, есть некоторые критические исправления, полученные после 7.1.0, такие как неправильная пересылка ошибок потока и т. Д. (Https://github.com/sindresorhus/got/releases/tag/v8.0.1)

Я пробовал обновить got , но все равно иногда застреваю, но все равно стоит это сделать. Просто обратите внимание, что материал downloadProgress потребует либо отключения, либо более приятного вывода, потому что терминал / консоль получает спам с прогрессом при использовании этого

Мне удалось запустить gatsby develop примерно через 25 минут, но мне пришлось уменьшить параллелизм в create-remote-file-node.js с 200 до 20. Я получил около 22 ошибок TimeoutErrors (но были повторно загружены при выполнении gatsby develop снова) после помещения журналов в этот пустой улов в 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 значительно сократило время сборки моего репозитория репро, но по-прежнему постоянно занимало почти час в последний раз, когда я пытался.

@dustinhorton, какая часть сборки source and transform data поскольку мы не указываем явно, сколько времени занимает загрузка файлов)?

У меня есть 150 МБ изображений с подключением к Интернету 1 ГБ. Теперь он работает. Мне нужно 30 секунд, чтобы скачать и продолжить сборку.

У меня также постоянно возникает эта проблема. Обновление got не решило эту проблему. Есть ли успех с добавлением дополнительной трассировки в source-wordpress, чтобы мы могли попытаться отладить, в чем проблема?

Пытался изменить concurrentRequests и perPage , а также обновить got до последней версии, но ничего не помогло. Прямо сейчас я могу получить categories , posts , pages и tags , но когда я добавляю users или media , сразу после =END PLUGIN=== плагин возвращается с ошибкой: TypeError: Cannot read property 'id' of undefined .

Если я включу все маршруты и внесу в черный список те, к которым у меня нет доступа, я получу =END PLUGIN=== но он никогда не завершится ... Это касается множества веб-сайтов, которые я тестировал, поэтому я полагаю, что это может быть моя система каким-то образом . Если кто-то хочет это проверить, вот конфиг:

    {
      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, который мне _ удалось_ получить, был https://wesbos.com/

СЧАСТЛИВОЕ ОБНОВЛЕНИЕ: мне удалось заставить его работать (_ для небольших сайтов_) с includedRoutes , даже с users и / или media , включив taxonomies в запрос . Теперь я не получаю ошибку 'id' of undefined : D

@pieh Я считаю, что users и media зависят от taxonomies , поэтому, может быть, они должны использоваться по умолчанию, когда конфигурация содержит какой-либо из этих типов? Сообщите мне, если я смогу помочь в устранении неполадок! В заключение, эта ошибка taxonomies кажется не связанной с бесконечным процессом сборки. С сайтами, размер которых превышает ~ 500 медиафайлов, я все еще не могу завершить процесс сборки!

ОБНОВЛЕНИЕ № 2 : Итак, мне удалось заставить его работать для queroinvestiragora.com , который содержит 600 медиафайлов, но только 70 сообщений, это занимает примерно 15 секунд после =END PLUGIN=== , но это работает. Однако в 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, чтобы определить это и получить фактические ответы сервера. Поскольку эти узлы не завершаются и не имеют идентификаторов, они не регистрируются в кеше. Файлы tmp удалены, а исходная файловая система gatsby была неполной. По какой-то причине (я еще не смотрел так далеко) после повторного запуска сценария сборки исходная файловая система была затем удалена, вероятно, потому, что сценарий обнаружил, что файловая система недействительна или неполна. Именно этот процесс был для меня созданием цикла и возникновением ошибок при будущих сборках, поскольку файловая система никогда не завершается.

Я работаю над исправлением, которое, похоже, устраняет некоторые проблемы, по крайней мере, в отношении большого количества изображений. Когда сценарий разработки или сборки успешно загружает все изображения в первый раз, он впоследствии не удаляется, а затем процесс сборки происходит довольно быстро, поскольку изображения правильно кэшируются файловой системой gatsby-source! Моя сборка упала с 15 минут до 1 минуты.

Я не уверен, связано ли это со сборками, в которых есть большое количество сообщений. Моя проблема была напрямую связана с загрузкой 1,6 ГБ данных изображений.

Я впервые работаю с плагинами исходного кода для gatsby, поэтому, если у кого-то есть какие-либо мысли или советы по этому поводу, я был бы признателен! Я смогу опубликовать свое репо позже сегодня. Я работаю над тем, чтобы он без проблем использовал мою локальную версию gatsby-source-filesystem.

Привет,

В продолжение моего комментария несколько дней назад. Вот мое репо.

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

Я использую монорепозиторий в этом проекте, поэтому вот несколько шагов, если вы хотите запустить репозиторий локально.

1. Убедитесь, что у вас установлена ​​последняя версия Yarn 1.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. Затем я использую функцию downloadRunner для регулирования запросов, чтобы они не попадали на сервер сразу, а также для повторной попытки отклонения обещаний. Я добавил дроссель 200 мс между каждым запросом createRemoteFileNode. Я уверен, что это значение можно изменить, и некоторые из них лучше подходят для непосредственного добавления в 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 ) не стоит об этом беспокоиться. Одна вещь, которая потенциально проблематична, заключается в том, что дроссель 200 мс - возможно, мы могли бы начать без него, и когда мы начнем видеть проблемы, автоматически применим дросселирование (для каждого имени хоста)

@pieh Да, вероятно, это createRemoteFileNode должен справиться с этим самостоятельно.

Однако особенно проблематичным является текущее поведение молчаливого отказа от ошибок и возврата null. На мой взгляд, должно быть какое-то сообщение о неудаче или успехе операции. Я думаю, что createRemoteFileNode можно было бы сделать более надежным с помощью следующих функций.

1) Жадно создавайте связи
2) Если есть ошибки от сервера, начните дросселировать и / или повторите попытку, если необходимо
3) Установите нормальные значения по умолчанию для дросселирования / повторной попытки
4) Создайте точку входа для настройки троттлинга / повторной попытки.
4) Отклонить обещание, если по какой-то причине узел не может быть обработан.

Я также могу сказать, что здесь я играл со значениями тайм-аута 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 docs. Я понимаю, что вы говорите о том, что queue может справиться с этим самостоятельно.

@njmyers, отличное расследование! Определенно согласен с тем, что загрузка файлов должна быть намного умнее!

На самом деле было бы неплохо извлечь часть загрузки файла в свой собственный пакет, который фокусируется на этой проблеме загрузки и кэширования удаленных файлов.

Есть большая вероятность, что нам понадобится использовать эту функциональность в нескольких местах в Gatsby и в будущем, и это то, что другие люди в Интернете также захотят использовать.

@KyleAMathews Вы имеете в виду извлечение createRemoteFileNode в отдельный пакет?

Не только загрузка и кеширование файлов. Затем createRemoteFileNode просто вызовет этот пакет и вернет обещание, которое разрешится, когда файл будет загружен (или возвращен из кеша).

У меня такая же проблема с моим собственным плагином исходного кода кабины.

Я так понимаю, это было бы больше похоже на извлечение этих частей кода в отдельный пакет ...

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

Кажется, это код, который специально занимается загрузкой и кешированием, пожалуйста, поправьте меня, если я ошибаюсь. Рад работать над этим! Просто пытаюсь понять, как это работает в большей экосистеме.

Будет ли принят PR только для исправления gatsby-source-wordpress, а затем извлекать исправление? Возникли проблемы с использованием плагина

@dustinhorton не уверен, что это поможет, но я обнаружил, что если вы хотите использовать локальный плагин, лучше всего указать gatsby непосредственно на файл package.json. У меня были проблемы с тем, чтобы gatsby нашел мой локальный плагин, пока я не начал его явно указывать.

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 и я хочу убедиться, что выполняю ее правильно, чтобы ее можно было должным образом интегрировать в экосистему.

@njmyers Вы в основном правы с выбором кода - мы также хотели бы, чтобы наша текущая очередь (которая ограничивает банкомат до 200 одновременных запросов, что кажется не очень подходящим для локальных разработчиков и, по-видимому, для wordpress), была перемещена и, вероятно, изменена.

@dustinhorton Я думаю, что разумно сначала использовать это в плагине wordpress (в основном потому, что это практически сделано).

@pieh Большое спасибо за разъяснения! Начну работать над новым плагином.

Что касается временного исправления wordpress-source, мой единственный другой вопрос - что здесь делать

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 . Я дам ему еще одну попытку в ближайшее время.

Более точно воссоздан ваш монорепозиторий, и, как ни странно, он просто сидит на source and transform nodes , как это было с не разветвленным gatsby-source-wordpress до понижения версии полученной зависимости.

@pieh Может ответить на его запрос @ https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -442536931?

@dustinhorton Да, он unhandled promise rejection если удаленный файл не может быть загружен. Вот почему я хотел бы иметь какой-то механизм для правильной обработки этого сценария.

Думаю, я также читал в другой ветке, что также говорилось об интеграции какого-то менеджера прогресса, поскольку это дало бы обратную связь о статусе плагина.

Если вы заглянете в файловую систему своей ОС в разделе project-root / .cache / gatsby-source-filesystem, вы сможете увидеть все загружаемые изображения. В моем случае сейчас почти 400 изображений, так что это займет довольно много времени. Однако перед использованием моей разветвленной версии плагин молча отказывался от ошибки, а затем никогда не прогрессировал, вызывая проблему, когда исходный код и преобразование занимали несколько часов ...

У вас есть репо? Я хотел бы иметь возможность попробовать его на другом сайте, поскольку до сих пор я тестировал его только в реальной жизненной ситуации на своем сайте.

@njmyers Это было бы правилом - если вы не против, напишите мне по электронной почте: [email protected] или просто ищите приглашения. Я приготовлю что-нибудь сегодня вечером.

Обновление got решило и для меня тоже.

Проблема с got@9 том, что для него требуется узел 8 (https://github.com/sindresorhus/got/releases/tag/v9.0.0), поэтому мы не можем обновить банкомат :(

Мы сможем выполнить обновление как минимум до got@8 , но я не уверен, что это решит проблемы.

got@8 похоже, реализует HTTP-кеширование в соответствии с RFC 7234, поэтому gatsby-source-filesystem может предоставить свой собственный адаптер кеша файловой системы. Это должно, по крайней мере, сократить время, затрачиваемое на исходные узлы и узлы преобразования во второй раз, учитывая, что ресурс кэшируется.

Привет!

Этот вопрос утих. Жуткая тишина. 👻

У нас много проблем, поэтому в настоящее время мы закрываем их после 30 дней бездействия. Прошло не менее 20 дней с момента последнего обновления здесь.

Если мы пропустили эту проблему или вы хотите оставить ее открытой, ответьте здесь. Вы также можете добавить ярлык «не устаревший», чтобы проблема оставалась открытой!

Спасибо, что присоединились к сообществу Гэтсби! 💪💜

@gatsbot По-прежнему проблема.

Меня попросили написать для вас сообщение в блоге. Не могу этого сделать, так как он застрял на узлах источника и преобразования. Увидел другую проблему, но я не вижу, где есть исправление. Это форк gatsbyjs, последний апстрим. Мне удалось запустить это только один раз. В нем всегда застревают трансформирующие узлы.

Во время сборки не удается получить скриншоты с нескольких сайтов. Утром добавлю проблемные сайты.

@ twhite96 Я только что столкнулся с проблемой, и у меня сработало удаление временных файлов, которые у меня все еще были открыты (из emacs), не уверен, поможет ли это вам или нет, но это позволило моей сборке продвинуться вперед.

Похоже, это все еще проблема ...

столкнулся с той же проблемой при использовании gatsby-source-s3, чтобы вытащить 100 фотографий и преобразовать их в резкость. Кто-нибудь придумал, как исправить?

Каким-то образом мою проблему исправили (случайно?). Вот шаги, которые я предпринял: я создал новое ведро s3 с меньшим количеством изображений (для тестирования), а затем попытался построить, и он очень быстро построился успешно. Затем я решил вернуться и попытаться вытащить из исходного ведра, и теперь внезапно он успешно построился за 49-е годы, хотя изначально он мог работать часами. Я не знаю, как простой переключатель в звеньях ковша исправил срыв, но надеюсь, что это поможет кому-то в этом разобраться. может это связано с кешем?

Всем привет. Я обновил свою локальную версию плагина, которую использовал для сайта, на котором возникла эта проблема. Я думаю, что это лучшая реализация, поскольку она использует «better-queue» перед «createRemoteNode» и передает параметр «concurrentRequests». Это немного избыточно, поскольку createRemoteNode уже использует очередь, но, несмотря на это, эта версия, похоже, хорошо работает с последними обновлениями gatsby и дает обратную связь о состоянии файлов. Я постараюсь собрать для этого пиар. Извините за задержки, я знаю, что сказал, что буду работать над этим раньше, но был очень занят!

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

@njmyers

Большое спасибо. Ваша версия решила некоторые мои проблемы. Я объединил это с одной или двумя строками, чтобы отфильтровать загрузку 25 ГБ mp3, и теперь я готов!

Определенно все еще проблема.
Я пытался скомпилировать свой проект последние 24 часа. Примерно из 12 попыток 3 удалось с выходами и фактическим WP-подключением. Есть ли что-нибудь исправить?
Кстати, я пробовал использовать версию плагина @njmyers (на самом деле

@lucassilvagc, можешь опубликовать какие-нибудь выводы? Я рад, что люди пробуют и тестируют ветку. Давайте сделаем так, чтобы он работал лучше, чтобы мы могли открыть PR!

@njmyers Конечно!

Краткий обзор происходящего:

Мой веб-сайт в настоящее время работает с ~ 1940 файлами изображений, возможно, это ошибка WordPress, создавшая несколько файлов изображений несколько раз. Если я использую ванильный _gatsby-source-wordpress_, проблема будет выглядеть так, как задумано (есть "ванильная" сборка, которую я сделал вчера вечером в другой среде сборки, которая возвращает ту же проблему, которую мы обсуждаем в целом по этой проблеме. Это build работает и компилируется, когда возвращаются все файлы изображений). Используя ваш плагин (заменяя все файлы внутри node_modules / gatsby-source-wordpress (поправьте меня, если я ошибаюсь)), _gatsby develop_ возвращает мне следующее:

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). Я просто не знаю, верны ли маршруты, которые я перечислил, или я что-то упускаю после.

Я очень доволен вашим ответом, эта проблема в настоящее время является огромным препятствием для моего проекта, и я рад, что вы все еще не знаете эту проблему. Большое спасибо!

Такая же проблема с 400+ настраиваемыми сообщениями с полями acf и 4000 изображениями.

Я обновил got и смог построить за 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"
  }

в вашем проекте Гэтсби 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

Как вы можете видеть, он вызывает console.log с прогрессом загрузки каждого файла каждый раз, когда генерируется событие downloadProgress которое происходит слишком много раз в секунду. Раньше это не было проблемой, потому что старая версия got не реализует событие downloadProgress .

Может, пиаром поправим? Похоже на отладку оставшегося кода.

У меня была такая же проблема, я застрял на «узлах источника и преобразования». После большого количества console.logs моя проблема закончилась тайм-аутом при извлечении медиафайлов из wordpress. Проблема заключалась не в том, что сервер не мог с этим справиться, а в ограничении скорости облачных вычислений и выдаче таймаутов после примерно 350 запросов.

Я обошел cloudflare, перешел прямо к vps, и я больше не вижу «узлы источника и преобразования», и моя сборка завершается.

Мое обходное решение заключалось в том, чтобы иметь локальный wordpress для тестирования, рабочий сайт находится в 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 смог создать сайт, но у меня не было локального подключения, так как скорость загрузки составляла всего 1 МБ / с, что привело к тому, что он отключился по таймауту через 30 секунд и завершился ошибкой на большом изображении.

У меня есть 1 ГБ волокна и нет «массивных» изображений.

Я не трансформирую изображения в блогах локально после их загрузки в wordpress, я просто использую их URL. Было бы неплохо, если бы была настройка, запрещающая загрузку этих изображений в этом случае.

Ребята, мне удалось это исправить, запустив запросы createRemoteFileNode последовательно, а не параллельно.

Да, проблема действительно основана на том факте, что createRemoteFileNode использует параллелизм 200, что слишком много для большинства серверов WP. У меня есть изображения на CloudFront, и я достиг некоторых ограничений по скорости.

Некоторое время я пытался решить проблему с помощью разветвленной версии исходного плагина, но на самом деле проблема не в gatsby-source-wordpress а в gatsby-source-filesystem . В идеале потребители функции createRemoteFileNode могли бы передавать туда параллелизм. Тогда плагины могут сделать опцию параллелизма доступной в своих конфигурациях. Я все еще хотел бы сделать пиар для решения этой проблемы!

Решение, которое я использовал, - это простой скрипт для изменения кода внутри 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, проблема сразу же решилась.

Я тоже обнаружил, что это так. Ранее у меня было одно изображение, которое приводило к сбою сборки, и я отклонил проблему Cloudflare. Проблема с тех пор возникла недавно, и поскольку @amcc предложил не маршрутизировать запись A через Cloudflare, проблема также была немедленно решена локально.

Просто хотел повторить, что это не только проблема с источником WP - столкнулся с той же проблемой с gatsby-source-prismic , уменьшив параллелизм файловой системы с помощью хака

Согласитесь, что если ничто иное, параллелизм исходной файловой системы должен быть настраиваемым.

@njmyers Мне жаль спрашивать об этом, но как именно выполняется это исправление. Просто запустите сценарий перед сборкой, или мне нужно каким-то образом ссылаться на сценарий в процессе сборки, потому что в настоящее время я спрашиваю себя, как применить это исправление локально, а также, например, на netlify.

@alexanderwe Не беспокойтесь, это все node_modules . Я не уверен на 100%, но считаю, что postinstall в вашем проекте package.json файл будет работать.

Для меня Гэтсби 50% времени зависает на «узлах источника и преобразования», когда я использую json с более чем 500 встроенными изображениями. Я использую 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
Затем представьте еще один PR для gatsby-source-wordpress и других, чтобы фактически сделать это настраиваемым из их ссылки в gatsby-config.js

@sebastienfi Я только что наткнулся на этот https://github.com/gatsbyjs/gatsby/issues/14819#event -2418874313 и соответствующий коммит https://github.com/gatsbyjs/gatsby/commit/90aa24787b32ef9613b6becbbecef1875d2d2d2ecbfadabe6d8d2d2ecb6ecbfadb6e6d8d2ecb добавляет переменную среды для настройки скорости параллелизма, что решило проблему для меня. Также продолжается обсуждение переменных среды и параметров конфигурации: https://github.com/gatsbyjs/gatsby/issues/14636

Вы пробовали установить в GATSBY_CONCURRENT_DOWNLOAD меньшее число? По умолчанию установлено 200.

Linux / mac:
GATSBY_CONCURRENT_DOWNLOAD=5 gatsby build

Windows:
setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build

@wardpeet
я пробовал, ничего не изменилось

Это определенно имеет какое-то отношение к исходной файловой системе, поскольку журналы показывают, что изображения были успешно извлечены .... проблема все еще огромна ... мы опаздываем в наш крайний срок, и мы действительно ищем решение этого ...

после установки плагина исходного кода wordpress для отладки я вижу это

всегда зависает в диапазоне 470-480 ... хотя обычно не в одном и том же месте.

кто-нибудь знает, где в коде это выполняется?

В итоге заставил его работать, переключив vpn на полпути

Кто-нибудь готов поделиться со мной своим репо и учетными данными, чтобы я мог попробовать это и попытаться найти проблему?

Не стесняйтесь присылать мне личное письмо на [email protected]

Мое репо не так легко воссоздать на данном этапе - у меня есть резервная копия базы данных, как это было где-то, но для создания сайта мне пришлось каждый месяц сокращать количество сообщений в один пост на годы содержания.

@wardpeet отправил вам мое репо Ward ([email protected]). дайте мне знать, как это происходит.

Наша компания изменила Wi-Fi и увеличила пропускную способность. Сегодня у меня не было проблем с загрузкой изображений .... Но я все еще не понимаю, это сеть или параллелизм?

однако все сборки на Netlify терпят неудачу ...

17:13:43: === [Получение wordpress__wp_media] === https://wildkiwi.com/wp-json/wp/v2/media
17:13:43: Всего сущностей: 1717
17:13:43: Запрошенных страниц: 344
5:13:45 PM: Запрос не выполнен с кодом ошибки "undefined"

код ошибки не определен, поэтому я действительно не понимаю, что происходит ...

Когда я меняю количество одновременных запросов на 5, он работает на Netlify

У меня была эта проблема с другим плагином (https://github.com/angeloashmore/gatsby-source-prismic), и установка GATSBY_CONCURRENT_DOWNLOAD=50 сработала.

Это произошло совершенно неожиданно (в один прекрасный день мой сайт будет построен, а в следующий - нет, без изменений), и без каких-либо сообщений об ошибке развертывать веб-сайты для клиентов, не будучи уверенным, что это больше не повторится.

Обычно мы загружаем 200 изображений за раз, но это может быть проблематично для некоторых компьютеров / подключений к Интернету. Хорошее решение - включить некоторые механизмы повтора.

У меня были эти проблемы, но мне удалось заставить сборку нормально работать с комбинацией setx GATSBY_CONCURRENT_DOWNLOAD 5; gatsby build и Smushing всех изображений (некоторые из которых были чрезмерно большими по размеру и размеру файла), используя бесплатную версию https: // en-gb.wordpress.org/plugins/wp-smushit/.

Привет! У меня такая же проблема с исходным плагином, который я создаю (не связанный с WordPress), и при загрузке более 1000 изображений из API. Он почти всегда зависает в конце процесса.

Установка GATSBY_CONCURRENT_DOWNLOAD не решила. Я пробовал 50 , 20 , 5 , не повезло.

Я получаю набор размеров из API, и я использовал самое большое изображение, но изменил его на самый маленький и тоже не исправил.

Трудно определить, почему он терпит неудачу на данный момент, единственное, что я получаю, это source and transform nodes а затем тишина навсегда.

Было бы здорово иметь для этого механизм отладки.

У меня возникла та же проблема при интеграции gatsby + wordress. Сборка навсегда остановится в API onCreateNode, где я использовал createRemoteFileNode.

Решение: я обновил файловую систему 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 я застреваю после "END PLUGIN".

...
=== [ 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 носителей, я всегда застреваю в конце шага загрузки удаленных файлов, иногда отсутствует только один носитель ...

Изменить: на этот раз сборка прошла успешно с 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

Надеюсь, это поможет

Похоже, это необычный вопрос. Вот мой опыт с этим:

• ❌ Я видел эту проблему в macOS High Sierra (с использованием iTerm)
• ✅ Я начал использовать GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop и проблема исчезла (так было пару недель)
• ❌ Я обновился до Mojave и обновил свою глобальную установку Gatsby до 2.7.47 а затем снова начал замечать проблему (используя iTerm)
• ❌ Пытался изменить GATSBY_CONCURRENT_DOWNLOAD на 5
• ❌ Пытался сдуть .cache и node_modules
• ❌ Пытался изменить размер окна iTerm при запуске gatsby develop (как с 50, так и с 5)
• ❌ Выполнить GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop в приложении "Терминал", а не в iTerm
• ✅ Две недели спустя попытался использовать GATSBY_CONCURRENT_DOWNLOAD=50 gatsby develop в iTerm и пару раз изменил размер окна во время процесса, и это сработало.

Преждевременно подумал, что у меня работает с той последней, но потом она зависла. Надеюсь, это поможет другим. По-прежнему кажется, что это не совсем понятно, но мы продвигаемся к цели медленно, но верно.

Обновление: сегодня это сработало для меня. Не уверен, что это потому, что я изменил размер окна iTerm в нужный момент в процессе или потому, что я наблюдал, как он увеличился с 93% до 100%, но на этот раз что-то было по-другому.

Дополнительно, чтобы использовать GATSBY_CONCURRENT_DOWNLOAD = 5, добавьте следующий код в свой файл gatsby-node.js

// Интернационализация
export.onPostBuild = () => {
ChildProcess.execSync ("ps aux | grep jest | grep -v grep | awk '{print $ 2}' | xargs kill")
console.log ('Копирование локалей')
fs.copySync (path.join (__ имя каталога, '/ src / locales'), path.join (__ имя каталога, '/ public / locales))
}

532314892 @bradydowling :

Не уверен, что это потому, что я изменил размер окна iTerm в нужной точке

Испытывая ту же проблему, я изменил размер окна iTerm и бац - он тоже внезапно продолжился. Не знаю, дикое совпадение это или ...

@bradydowling @davegregg Ого , какой странный. Изменение размера окна iTerm помогло.

@TylerBarnes Что бы это ни было, я бы предположил, что это не специфично для Wordpress. Я не использую вообще ничего связанного с Wordpress.

@beauhankins Как насчет тебя?

@davegregg @beauhankins @bradydowling может ли кто-нибудь из вас поделиться репо, где это происходит? Кажется действительно странным, что изменение размера окна терминала решает проблему.

@TylerBarnes, вот репо, где я его видел. Я немного не касался этого.

Боковое примечание: как вы справляетесь с ситуацией, когда вы клонируете сайт Gatsby с более старой версией Gatsby, чем та, которая в настоящее время установлена ​​с помощью интерфейса командной строки?

Я запускал комманды в терминале кода VS (я использую bash). Это длилось вечно, и, как было предложено выше, я вышел из полноэкранного режима, и это сработало.

@bradydowling, спасибо, что поделились своим репо! Для использования более старых версий Gatsby, чем cli, вы можете создать сценарий 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. Я понимаю, что это было опубликовано около года назад, и с тех пор Гэтсби значительно изменился. При запуске его на моем компьютере (и установке версии gatsby на * в package.json) сборка, похоже, завершается примерно за 2000 секунд (~ 33 минуты).
Кроме того, при обновлении cli теперь есть индикатор выполнения, который имеет огромное значение с точки зрения того, как долго он «ощущается», поскольку вы получаете более конкретный цикл обратной связи.

Шаг поиска занимает почти все это время (1968/1975 секунд). Загрузка удаленных файлов самая большая (1845 секунд).

Это меня не удивляет, когда я смотрю на один-единственный обход этого сервера:

# 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 ресурсов. Учитывая, что один запрос занимает от 2 до 4 секунд, я не удивлен, что это занимает так много времени.

Тем не менее, я замечаю некоторые паузы во время основного отрезка загрузки в 1845 секунд. Я не уверен, просто ли это сервер ограничивает данные или нет (я установил для параллелизма значение 5).

Я действительно пытался покачивать ширину терминала (я использую xfce linux, fwiw), и хотя это иногда совпадало с прогрессом, идущим вперед, сейчас я убежден, что это скорее совпадение, чем причинно-следственная связь.

Итог: хотя я могу воспроизвести медленную загрузку и, казалось бы, «застрявший» прогресс, все признаки в настоящее время указывают на то, что это в значительной степени вызвано ожиданием ответа сервера. Вдобавок ширина терминала не влияет на это.

Тем не менее: существует вероятность того, что вывод терминала каким-то образом застрянет при обновлении индикатора выполнения на очень определенной ширине. Хотя это маловероятно, это возможно. Следовательно, нам действительно нужна репродукция, которую мы можем запустить самостоятельно (так что без авторизации). И предпочтительно тот, который _не_ зависит от удаленного сервера, так как я не хочу забивать сервер.

Я собираюсь соответствующим образом обновить ярлыки по этому вопросу.

Репро, опубликованное в https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -438667221 от @njmyers, больше не существует.

Репо, опубликованное в https://github.com/gatsbyjs/gatsby/issues/6654#issuecomment -562607399 от @bradydowling, требует нескольких разрешений, которых у меня нет, и, похоже, имеет аналогичные проблемы с временем поездки туда и обратно

@ 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

Кстати, это файлы размером 6 МБ. Я использую соединение со скоростью 250 Мбит / с, что вполне подходит для обработки данных быстрее, чем 1 Мбит / с, но меня не удивляет, что это увеличивает время загрузки. Никакое изменение размера cli не ускорит это;)

Интересный. Это просто стандартный личный блог WordPress, размещенный на EC2, так что это не похоже на гигантскую установку. Возможно, это потому, что все эти запросы перегружают хост. Или я не эксперт по WordPress, но, возможно, существует какое-то стандартное ограничение скорости WP для вызовов REST API, которое может произойти? Я также исхожу из предположения, что такое поведение не уникально для этого сайта.

Возможно, это потому, что все эти запросы перегружают хост.

Это мое предположение (или что-то в этом роде). Но я немного исследую нашу собственную архитектуру, чтобы проверить, не теряем ли мы эффективность из-за абстракций. Но, учитывая, что я могу имитировать большинство случаев, о которых сообщалось, с помощью простых wgets / curls, я сомневаюсь, что там много чего.

Итак, я заменил биты 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, можете ли вы отладить некоторые ссылки, которые загружаются для вашего сайта во время поиска, и вручную проверить, быстро ли они загружаются? Как я уже упоминал выше, я вижу одну большую проблему в том, что некоторые хосты wp просто супер-медленные.

Так что, если хост работает медленно и есть много контента для загрузки, то да, этот шаг займет много времени, потому что это все, что он должен делать на этом шаге; откройте для себя контент и загрузите его :)

Если вы подтвердили, что сам контент загружается за часть всего шага, вернитесь сюда. В этом случае репродукция была бы чрезвычайно полезна :)

Возможно, в идеальном мире вы могли бы передать Гэтсби флаг, который будет кэшировать
загрузка ресурса сайта, поэтому это не нужно делать повторно.

Другое оптимальное решение - разрешить флаг, который устанавливает какой-то
ограничение скорости или дросселирование загрузки ресурсов, чтобы она не прерывалась
гостья.

Есть какие-нибудь мысли по поводу этих двух идей?

В чт, 19 декабря 2019 г., 18:09 Питер ван дер Зи [email protected]
написал:

@Vacilando https://github.com/Vacilando, можете ли вы отладить некоторые ссылки,
загружаются для вашего сайта во время поиска и тестирования вручную
качаются ли они быстро? Как я уже упоминал выше, одна большая проблема - я
Видно, что некоторые хосты wp просто супер-медленные.

Так что, если хост медленный и есть много контента для загрузки, тогда да
этот шаг займет много времени, потому что это все, что он должен делать в
этот шаг; откройте для себя контент и загрузите его :)

Если вы подтвердили, что сам контент загружается за долю
весь шаг, пожалуйста, вернитесь сюда. В этом случае репродукция будет
очень полезно :)

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/gatsbyjs/gatsby/issues/6654?email_source=notifications&email_token=ABS4AU62367MTEWP7LJXWTLQZP5L5L5A5CNFSM4FLHT3T2YY3PNVWWK3TUL52XG43JNV45PNVWWK3TUL52XG4DFV45
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ABS4AU7GCV4YMZQH6R37BSDQZP5L5ANCNFSM4FLHT3TQ
.

@bradydowling - часть этого уже существует. Вы можете установить переменную env GATSBY_CONCURRENT_DOWNLOAD чтобы настроить ограничение для одновременных запросов. В следующей основной версии gatsby-source-wordpress https://github.com/gatsbyjs/gatsby/issues/19292 будет больше контроля над загрузкой медиафайлов. Что касается кеширования, загруженные файлы в настоящее время кэшируются, но когда вы меняете файл gatsby - *. Js, он в настоящее время стирает кеш, чтобы устаревший кеш не приводил к неожиданным ошибкам. Так что это основная проблема, а не специфическая для gatsby-source-wordpress , но всегда ведется работа по улучшению кеша Gatsby.

Частично Api заданий (№ 19831) должен решить эту проблему с кешированием.

Я. Видел бит про GATSBY_CONCURRENT_DOWNLOAD ближе к верху. По моему опыту, это не помогло, поэтому я предполагаю, что я предложил более детальный контроль, например, в мегабайтах на с / м / ч или что-то в этом роде. Может я просто чушь говорю.

@bradydowling Я ищу возможность добавления повторных попыток запроса с экспоненциальной задержкой, а также добавления дополнительной настройки для максимального количества запросов в секунду для случаев, когда это не работает достаточно хорошо.

Привет!

Этот вопрос утих. Жуткая тишина. 👻

У нас много проблем, поэтому в настоящее время мы закрываем их после 30 дней бездействия. Прошло не менее 20 дней с момента последнего обновления здесь.
Если мы пропустили эту проблему или вы хотите оставить ее открытой, ответьте здесь. Вы также можете добавить ярлык «не устаревший», чтобы проблема оставалась открытой!
В качестве дружеского напоминания: лучший способ увидеть эту или любую другую исправленную проблему - это открыть запрос на слияние. Посетите gatsby.dev/contribute для получения дополнительной информации об открытии PR, сортировке проблем и внесении вклада!

Спасибо, что присоединились к сообществу Гэтсби! 💪💜

Я собираюсь закрыть это сейчас.

Если вы считаете, что у вас возникла проблема с поиском wordpress, пожалуйста, сначала подтвердите, что ваши задержки не вызваны медленным сервером wordpress. Затем откройте _новую_ проблему (но не стесняйтесь возвращаться к этой проблеме).

Большое количество комментариев затрудняет отслеживание обсуждения. Таким образом, открытие нового вопроса с большей вероятностью приведет к тому, что ваша конкретная проблема получит ответ.

Я и другие подтвердили это за последние полтора года. моя первоначальная проблема была на хорошо настроенном vps. У @njmyers было вероятное исправление или, по крайней мере, улучшение, но они не смогли получить никаких ответов от сопровождающих о том, как они хотели бы это сделать.

Я думал о том, чтобы закрыть себя, но я думаю, что это должно быть как предупреждение о том, что умеренно большой сайт wordpress пока НЕ ​​подходит для gatsby.

@dustinhorton Я понимаю это. Этому выпуску больше полутора лет, все быстро меняется. Из-за того, что проблема вызывает такое количество комментариев, уже трудно понять настоящую проблему.

Fwiw, как отмечалось выше, я проверил последние сообщенные репро и определил, что они, по крайней мере, были вызваны медленными пультами дистанционного управления. Если у вас есть репродукция с текущей версией Gatsby на быстром пульте дистанционного управления, дайте мне знать, даже если она, возможно, уже размещена в этой теме. Или, может быть, откройте для него новый выпуск (и отметьте меня), если вы хотите больше сосредоточиться на нем, я оставлю это вам :)

(_Просто для ясности, мы закрыли эту проблему, потому что она устарела из-за слишком большого количества сообщений не по теме, пожалуйста, не думайте, что мы подавляем обсуждение, поскольку это не намерение, и мы понимаем, что наша работа здесь не закончена ! _)