Настройка производительности потоков Power Automate

Поток Power Automate, который выполняет задачу за несколько минут, хотя на самом деле её можно было бы выполнить за секунды, отнимает не только время. Он без необходимости расходует значительную часть ограниченных запросов действий вашего тарифа, увеличивает количество ошибок тайм-аута в подключённых системах и усложняет диагностику, поскольку при каждом запуске приходится проходить больше шагов. Хорошая новость: большинство проблем с производительностью в Power Automate сводятся к трём рычагам, которые Microsoft подробно описывает в собственных рекомендациях по разработке. По состоянию на июль 2026 года.

В этой статье кратко описано, как с помощью целенаправленного параллелизма, сокращения ненужных действий и правильного выбора коннектора и данных вы можете создавать заметно более быстрые потоки — на основе официальной документации Microsoft по Power Automate. При этом вы сами решаете, какой рычаг даёт наибольший эффект именно для вашего потока, вместо того чтобы наугад крутить настройки, которые почти ничего не меняют.

Почему потоки вообще становятся медленными

Прежде чем оптимизировать, стоит разобраться в причине. Согласно руководству по диагностике проблем с производительностью, многие замедлившиеся потоки просто достигают своих дневных лимитов Power Automate. Анализ действий в разделе «Мои потоки» показывает, сколько запросов действий фактически расходует поток, а Power Automate даже уведомляет владельцев по электронной почте, если поток регулярно упирается в лимиты действий. Не менее важно: сами подключённые сервисы также устанавливают защитные ограничения, которые проявляются в потоке как ошибка 429 (слишком много запросов) или 5xx (тайм-аут). Эти ограничения различаются в зависимости от коннектора и сервиса, поэтому одна и та же логика потока может работать совершенно по-разному в SharePoint и в Dataverse или во внешнем API.

Рычаг 1: целенаправленное использование параллелизма

Параллельные ветви для независимых шагов

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

Управление параллелизмом в циклах «Применить ко всем»

Ещё заметнее этот эффект проявляется в циклах. По умолчанию цикл «Применить ко всем» работает последовательно, элемент за элементом. Документация на примере тестового массива из четырёх элементов показывает, насколько сильно это сокращается благодаря параллелизму:

• Параллелизм отключён: 21 секунда
• Степень параллелизма 2: 11 секунд
• Степень параллелизма 4: 6 секунд
• Степень параллелизма 6: 6 секунд

Вы можете задать степень параллелизма от 1 до 50. Важно: высокое значение не ускоряет всё автоматически, поскольку разделение работы, постановка в очередь дополнительных потоков и задержки со стороны вызываемой конечной точки сами по себе создают дополнительные накладные расходы. К тому же вложенные циклы «Применить ко всем» всегда выполняются последовательно — по данным Microsoft, настройка параллелизма действует только на верхнем уровне облачного потока.

Параллелизм триггера — только с осторожностью

На уровне триггера дополнительно можно включить управление параллелизмом, которое определяет, сколько экземпляров потока могут выполняться одновременно; по умолчанию оно отключено. Это помогает при работе с источниками данных с ограниченной пропускной способностью и предотвращает так называемые «грязные чтения» (dirty reads), при которых поток продолжает работать с устаревшими данными, потому что параллельный запуск тем временем изменил запись. Однако Microsoft прямо рекомендует соблюдать осторожность: после включения эту настройку уже нельзя отменить — только пересоздав триггер. В качестве рекомендуемой практики документация советует применять управление параллелизмом только к выделенному дочернему потоку с минимально возможным числом действий, а не ко всему основному потоку.

Рычаг 2: сокращение ненужных действий и циклов

Избегайте вложенных циклов

Руководство по антипаттернам в облачных потоках называет вложенные циклы «Применить ко всем» одной из самых дорогостоящих ловушек. Два цикла по десять итераций каждый дают в сумме 100 проходов; при больших объёмах данных это число растёт экспоненциально и быстро достигает лимитов по числу итераций и общему времени выполнения. Документированная альтернатива — использовать расширение запроса OData, чтобы загружать связанные записи в рамках одного запроса, вместо того чтобы дозагружать их во втором, вложенном цикле. Параметр вроде `Products($select=ProductName,Price)` заменяет весь внутренний цикл одним дополнительным вызовом RetrieveMultiple к Dataverse.

Условия триггера вместо последующих проверок

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

Пакетные и массовые операции вместо отдельных действий

Согласно документации, если нужно создать или обновить сотни или тысячи записей, не стоит обрабатывать каждую запись по отдельности в цикле For each. Пакетные операции объединяют несколько запросов в один HTTP-запрос, а веб-API массовых операций в Dataverse идут ещё дальше: вместо множества отдельных действий «Создать строку» один вызов веб-API CreateMultiple со 100 подготовленными записями засчитывается всего как одно действие.

Рычаг 3: выбор коннектора и ограничение объёма данных

Загружайте только те данные, которые вам действительно нужны

Согласно руководству «Работайте только с релевантными данными», объём обрабатываемых данных можно ограничить как на уровне триггера, так и на уровне отдельных действий. Для источников Dataverse параметры «Выбрать столбцы», «Фильтровать строки» и «Количество строк» уменьшают набор результатов непосредственно у источника. В SharePoint ту же роль выполняют «Запрос фильтра», «Максимальное число» и «Ограничить столбцы по представлению». Это важно, поскольку так называемые лимиты пропускной способности (throughput limits) ограничивают, сколько данных облачный поток может считывать и записывать из своей истории выполнения в течение определённого периода. Если этот лимит непрерывно превышается в течение 14 дней, Power Automate автоматически отключает поток.

Правильное действие вместо самого удобного

Выбор коннектора также означает, что для одной и той же задачи не стоит автоматически хвататься за самое ресурсоёмкое действие. Например, операции с данными, такие как Filter array, Select или Join, обрабатывают массивы напрямую и уменьшают объём данных, проходящих через последующие шаги, зачастую гораздо эффективнее, чем дополнительный цикл с условиями. Если сервис предлагает собственные параметры фильтрации или выбора прямо в коннекторе, согласно документации Microsoft эффективнее фильтровать именно там, а не сначала загружать в поток весь объём данных, а затем сокращать его отдельной операцией с данными.

Как найти узкое место в собственном потоке

Быстрее всего найти реальную причину поможет фиксированный порядок проверки. Сначала откройте анализ действий проблемного потока и проверьте, насколько близко он подошёл к своим дневным лимитам. Затем проверьте историю выполнения на предмет отдельных действий с заметно долгим временем выполнения — обычно это циклы без параллелизма или действия, загружающие неоправданно большие объёмы данных. Также проверьте, не появляются ли ошибки типа 429 или 5xx, которые указывают на ограничения подключённого сервиса, а не самого Power Automate. При более масштабных ландшафтах потоков с несколькими средами часто оправдана структурированная консультация по Power Automate, в рамках которой параллелизм, объём данных и выбор коннекторов систематически прорабатываются сразу для всех критичных потоков, вместо того чтобы оптимизировать каждый поток по отдельности.

Часто задаваемые вопросы

Сколько элементов стоит обрабатывать параллельно в цикле «Применить ко всем»?

Универсального оптимального значения не существует, Microsoft допускает степень параллелизма от 1 до 50. В документированном примерном измерении с четырьмя элементами параллелизм 4 уже давал максимальное ускорение, а дальнейшее увеличение до 6 больше никак не влияло на время выполнения. На практике имеет смысл начинать с умеренного значения, например 5–10, и наблюдать за временем выполнения в истории запусков, вместо того чтобы сразу устанавливать максимальное значение, поскольку слишком высокий параллелизм сам может создавать задержки со стороны вызываемой конечной точки.

Улучшает ли управление параллелизмом триггера производительность автоматически?

Не автоматически, и Microsoft даже рекомендует сдержанность. Настройка по умолчанию без управления параллелизмом допускает столько одновременных запусков, сколько может обработать система, чего уже достаточно для большинства сценариев. Управление параллелизмом имеет смысл прежде всего тогда, когда подключённый ресурс поддерживает лишь ограниченную пропускную способность или когда нужно предотвратить «грязные чтения» (dirty reads), а не как общая мера ускорения. Поскольку эту настройку нельзя отменить, применять её стоит только точечно — к небольшому выделенному потоку.

Почему вложенные циклы представляют собой такую серьёзную проблему производительности?

Потому что число проходов перемножается, а не складывается. Два вложенных друг в друга цикла по десять элементов каждый дают 100 отдельных проходов; при больших объёмах данных это число продолжает расти экспоненциально. Это не только отнимает время, но и быстро приближает поток к лимитам по числу итераций и общему времени выполнения, что в худшем случае приводит к ошибкам потока или троттлингу.

Какое отношение выбор коннектора имеет к производительности, если несколько коннекторов могут выполнить одну и ту же задачу?

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

Как понять, вызвана ли медлительность потока самим Power Automate или подключённым сервисом?

Ответ даёт взгляд на коды ошибок в истории выполнения. Ошибки типа 429 или тайм-ауты в диапазоне 5xx указывают на защитные ограничения подключённого сервиса, которые различаются в зависимости от коннектора. Если же сам Power Automate достигает своих дневных запросов действий, это чётко отображается в анализе действий в разделе «Мои потоки», а владельцы дополнительно получают автоматическое уведомление с рекомендациями по сокращению числа действий.