Как исправить ошибку при большом количестве fetch запросов?

Question

[sheeel]

let results = await Promise.all(filteredMatches.map((v) => handler(v.CI)))

handler - отправляет запрос на сервер и возвращает нужные данные
но тк одновременно отправляется много запросов(40-50) возвращет ошибку FetchError: invalid json response body at
Можно как то это исправить потому что если отправлять последовательно через какой либо цикл это займет много времени?

Comments

[Kovalsky]

А к какому сервису вы обращаетесь? Сторонние сервисы вполне могут подобными ограничениями защищаться от таких обстрелов запросами. Если сервис ваш, то конечно вопросов нет.

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

Answer 1

[Inviz Custos]

Есть удобная библиотека bluebird
bluebirdjs.com/docs/api/promise.map.html
Для map есть опция concurrency.
Соответственно, Ваш код можно переписать так:

const Promise = require('bluebird');
let results = await Promise.map(filteredMatches, v => handler(v.CI), { concurrency: 10 });

Вместо 10 можете указать любое удобное количество "потоков".

Comments

[Stalker_RED]

sheeel, а вы поставьте try catch на то место где у вас FetchError: invalid json response body, поставьте там брейкпоинт, и поглядите что там в body написано.
Скорее всего там не json, а ответ от сервера типа "ой всё".

Answer 2

[Stalker_RED]

Можно.
Купить сервер пошустрее, или купить побольше серверов.

Или научиться хоть немного думать о производительности еще на этапе проектирования :)

UPD: sheeel, вот ты мне не веришь, хотя скорее всего зря. Я там в комментах писал как проверить.

Попробую объяснить на пальцах что такое оверхед, и где у тебя архитектурный косяк.

Представь себе автомеханика, который ковыряется под капотом автомобиля, и у него есть паренек стажер на подхвате. И вот механик говорит стажеру - псс, парень, нужна гайка на 13!
И парень бежит на склад (недалеко, 20 метров всего), и говорит складовщику: нужна гайка на 13! Складовщик открывает книгу учета складских материалов, смотрит где у него хранятся гайки, идет к нужному стеллажу, открывает коробочку, вынимает гайку, кладет в пакетик, возвращается, отдает парню гайку, и записывает в журнал, что мол по запросу такого-то выдана гайка на 13, 1 штука, хотя парень уже убежал.

И все счастливы.

А потом вдруг слесарю понадобилось 50 гаек. И он 50 раз посылает помощника за гайками. И каждый раз парень носит по одной. И кладовщик (он чуток поумнее этого парня), уже не заглядывает в журнал чтобы узнать какой стеллаж ему нужен, у кладовщика для этого кеш в голове есть! Но он вынужден все равно открывать коробочку, вынимать гаечку, и записывать в журнал. Он бы и рад отдать 50 гаек в одном пакете, он так умеет! Но он четко следует инструкциям. Запрошена одна гайка - вот вам одна. А потом после 20 гаек у кладовщика обед, и парень возвращается не с гайкой, а invalid response.

Так вот, вы почему-то решили, что все упирается в скорость, с которой паренек бежит к складу и от склада. Это тоже важно, осбенно если склад далеко. Inviz Custos и Максим Зайцев подсказывают вам, что нужно больше пареньков, и как правильно их поставить в очередь у окошка. Это тоже важно, ага.

Но гораздо круче было бы запросить все 50 гаек за один раз.

Comments

[Kovalsky]

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