Низкая производительность при копировании из источника HTTP в приемник больших двоичных объектов

Я использую действие копирования для вызова HTTP API и сохраняю ответ json в виде файла в хранилище BLOB-объектов Azure. Действие копирования выполняется в цикле ForEach, и каждый запуск действия занимает 16 секунд, но когда я смотрю на детали выполнения, он говорит, что продолжительность копирования составляет всего 3 секунды. Тогда почему упражнение длится 16 секунд? Исходный набор данных - это Http-файл со связанной службой HttpServer, а набор данных-приемник - это json-файл хранилища BLOB-объектов. Наборы данных источника и приемника настроены с использованием двоичной копии, и это запрос GET на URL-адрес HTTPS с анонимной аутентификацией.

Я хотел бы ускорить эту активность, поскольку она выполняется несколько раз внутри цикла ForEach. Есть ли способ улучшить производительность?


person Magnus Johannesson    schedule 02.01.2019    source источник


Ответы (1)


При запуске действия всегда есть несколько дополнительных секунд. Также учтите, что http-сервер может также отвечать за некоторые из тех секунд, которые вы там видите.

Если вы используете для каждого цикла и хотите ускорить процесс, вы можете снять флажок «Последовательная проверка» на вкладке настроек действия foreach.

Надеюсь, это помогло!

person Martin Esteban Zurita    schedule 02.01.2019
comment
Спасибо, Мартин! Я не думаю, что http-сервер является узким местом в моем случае. Это платный API Google с ограничением в 50 запросов в секунду, и когда я вызываю его из Postman, он занимает ок. 100 мс. Я установил количество пакетов для цикла ForEach равным 50, поэтому он уже работает параллельно. Кажется много, что при запуске действия есть 13-секундные накладные расходы. - person Magnus Johannesson; 02.01.2019
comment
О, понятно, тогда я боюсь, что вы не сможете сократить это время с помощью фабрики данных. Если вам действительно нужно что-то более быстрое, вы можете рассмотреть другую технологию, например концентратор событий или потоковую аналитику, но я никогда не использовал ни одну из них. - person Martin Esteban Zurita; 02.01.2019