Тайм-аут соединения при получении данных из drupal для gatsby

Question

Я использую gatsby в качестве генератора c сайтов stati с drupal в качестве бэкэнда. Данные извлекаются с помощью плагина gatsby-source-drupal . Моя конфигурация для плагина выглядит следующим образом:

module.exports = {
  //Excluded irrelevant configurations
  plugins: [
    {
      resolve: 'gatsby-source-drupal',
      options: {
        baseUrl: 'https://example.org',
        apiBase: 'jsonapi',
        concurrentFileRequests: 120,
        disallowedLinkTypes: [
          //Standard disallows
          'self',
          'describedby',
          //Erroneous resources
          'block--block',
          'field_storage_config--field_storage_config',
          'menu--menu'
        ],
      },
    },
  ],
};

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

ERROR #11321  PLUGIN
"gatsby-source-drupal" threw an error while running the sourceNodes lifecycle:
connect ETIMEDOUT <Ip Address>:443

Этот сбой происходит для случайных базовых коллекций, что исключает возможность того, что конкретная c коллекция является проблемной c. Получение сбойного ресурса в контейнере с curl выполнено успешно. Я не думаю, что ограничение сервера - тоже проблема, поскольку поиск данных работает на моем хосте. Я сравнил использование памяти для обеих установок узла (v12), используя process.memoryUsage(), и получил аналогичные результаты.

Может быть разница между процессом узла на хост-машине и docker контейнером, который может вызывать проблемы ?

Answer 1

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

Я бы рекомендовал сначала попытаться снизить concurrentFileRequests до 10 и посмотреть, исчезнет ли проблема.

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

См. Также эту проблему: NodeJS таймауты запроса с параллелизмом 100