Решение проблем регулирования (429 — Слишком много запросов) в Azure Logic Apps
В Azure Logic Apps приложение логики возвращает ошибку «HTTP 429 — Слишком много запросов», когда количество запросов превышает частоту обработки, с которой может справиться назначение в течение определенного промежутка времени. Регулирование может привести к таким проблемам, как отложенная обработка данных, снижение быстродействия и появление ошибок, например превышение заданной политики повторов.
Ниже приведены некоторые распространенные типы регулирования, которые могут возникнуть в приложении логики.
Регулирование приложений логики
Служба Azure Logic Apps имеет собственные ограничения пропускной способности. Если приложение логики превышает эти ограничения, то регулируется ресурс этого приложения, а не только конкретного экземпляра или выполнения.
Чтобы найти события регулирования на этом уровне, проверьте панель Метрики приложения логики на портале Azure.
Откройте приложение логики в конструкторе приложений логики на портале Azure.
В меню слева в разделе Мониторинг выберите Метрики.
В разделе Заголовок диаграммывыберите Добавить метрику, чтобы добавить к существующей метрике еще одну.
В первой строке метрики в списке Метрики выберите События, регулируемые действием. Во второй строке метрики в списке Метрики выберите События, регулируемые триггером.
Для управления регулированием на этом уровне доступны следующие варианты.
Ограничьте количество экземпляров приложения логики, которые могут выполняться одновременно.
По умолчанию, если условие триггера приложения логики будет выполняться несколько раз одновременно, то несколько экземпляров триггеров для приложения логики выполняются параллельно, или одновременно. Это означает, что каждый экземпляр триггера срабатывает до завершения выполнения предыдущего экземпляра рабочего процесса.
Хотя количество экземпляров триггеров, которые могут выполняться одновременно, не ограничено, можно ограничить это число, включив параметр параллелизма триггера и при необходимости выбрав ограничение, отличное от значения по умолчанию.
Включение высокой пропускной способности.
Приложение логики имеет ограничение по умолчанию для количества действий, которые могут выполняться в течение 5-минутного интервала. Чтобы увеличить это ограничение до максимального количества действий, включите режим высокой пропускной способности в приложении логики.
Отключите режим депакетирования массива (параметр «Разделить на») в триггерах.
Если триггер возвращает массив для обработки оставшихся действий рабочего процесса, то параметр Разделить на для этого триггера разделяет элементы массива и запускает экземпляр рабочего процесса для каждого элемента массива, фактически выполняя несколько одновременных запусков до ограничения Разделить на. Для управления регулированием отключите поведение Разделить на, пусть приложение логики обрабатывает весь массив одним вызовом, а не по одному элементу за вызов.
Разбивайте действия на меньшие приложения логики.
Как говорилось выше, приложение логики ограничено количеством действий по умолчанию, которые могут выполняться в течение 5-минутного периода. Хотя это ограничение можно увеличить, включив режим высокой пропускной способности, есть также другой вариант — разбить действия приложения логики на более мелкие приложения логики, чтобы количество действий, выполняемых в каждом приложении, было в пределах ограничения. Таким образом вы сократите нагрузку на один ресурс приложения логики, распределив нагрузку между несколькими приложениями логики. Такое решение лучше подойдет для действий, которые обрабатывают большие наборы данных или запускаются для параллельного выполнения множества действий, итераций или действия в каждой итерации цикла, число которых превышает предел выполнения действия.
Например, такое приложение логики выполняет всю работу по получению таблиц из базы данных SQL Server и получает строки из каждой таблицы. Цикл for each параллельно проходит по каждой из таблиц, чтобы действие Получить строки возвращало строки для каждой таблицы. В зависимости от объема данных в таблицах такие действия могут превысить ограничение на количество выполнений.
После рефакторинга приложение логики разделится на родительское и дочернее приложения логики. Родительское приложение получает таблицы из SQL Server, а затем вызывает дочернее приложение логики для каждой таблицы, чтобы получить строки:
Ниже показано дочернее приложение логики, которое вызывается родительским приложением логики для получения строк для каждой из таблиц:
Регулирование соединителя
Каждый соединитель имеет собственные ограничения регулирования, которые можно найти на странице технического справочника по соединителю. Например, соединитель служебной шины Azure имеет ограничение регулирования до 6000 вызовов в минуту, в то время как соединитель SQL Server имеет ограничения регулирования, которые зависят от типа операции.
Некоторые триггеры и действия, например HTTP, имеют Политику повторов, которую можно настроить в зависимости от Ограничений политики повтора, чтобы реализовать обработку исключений. Политика повторов указывает, каким образом и как часто действие или триггер повторяет запрос после истечения времени ожидания первоначального запроса, либо запрос завершается ошибкой, т. е. выдается ответ 408, 429 или 5xx. Таким образом, когда регулирование запускается и возвращает ошибку 429, Logic Apps использует политику повтора, там где она поддерживается.
Чтобы узнать, поддерживает ли триггер или действие политику повтора, проверьте параметры триггера или действия. Чтобы просмотреть количество попыток триггера или действия, перейдите в журнал выполнения приложения логики, выберите запуск, который необходимо просмотреть, и разверните этот триггер или действие, чтобы просмотреть сведения о входных и выходных данных, а также обо всех повторных попытках. Например:
Хотя журнал повторных попыток содержит сведения об ошибках, возможно, это просто проблемы регулирования соединителя и регулирования назначения. В этом случае может потребоваться просмотр данных ответа или выполнение некоторых вычислений интервала регулирования, чтобы выяснить источник.
Для приложений логики в глобальной многоклиентской службе Azure Logic Apps выполняется регулирование на уровне соединения. Например, для приложений логики, выполняемых в среде службы интеграции (ISE), регулирование по-прежнему происходит для соединений, не связанных с ISE, так как они выполняются в глобальной многоклиентской службе Logic Apps. Но подключения ISE, созданные с помощью соединителей ISE, не регулируются, так как они выполняются в интегрированной среде сценариев.
Для управления регулированием на этом уровне доступны следующие варианты.
Настройте несколько подключений для одного действия, чтобы приложение логики секционировало данные для обработки.
Для этого варианта рассмотрите возможность распределения рабочей нагрузки путем разделения запросов действия на несколько соединений к одному назначению с использованием одних и тех же учетных данных.
Предположим, приложение логики получает таблицы из базы данных SQL Server, а затем получает строки из каждой таблицы. В зависимости от количества строк, которые необходимо обработать, можно использовать несколько соединений и несколько циклов for each, чтобы разделить общее количество строк на меньшие наборы для обработки. В этом сценарии используется два цикла for each для разделения общего количества строк пополам. Первый цикл for each использует выражение, которое получает первую половину. В другом цикле for each используется второе выражение, которое получает вторую половину. Например:
Выражение 1. Функция take() возвращает первую часть коллекции. Дополнительные сведения см. по функции take() .
@take(collection-or-array-name, div(length(collection-or-array-name), 2))
Выражение 2. Функция skip() удаляет начало коллекции и возвращает все остальные элементы. Дополнительные сведения см. по функции skip() .
@skip(collection-or-array-name, div(length(collection-or-array-name), 2))
Ниже приведен визуальный пример, демонстрирующий использование этих выражений.
Для каждого действия настраивайте собственное соединение.
Для этого рассмотрите возможность распределения рабочей нагрузки, распределив запросы от каждого из действий по собственному соединению, даже если действия подключаются к одной службе или системе и используют одни и те же учетные данные.
Предположим, приложение логики получает таблицы из базы данных SQL Server, а затем получает строки из каждой из таблиц. Можно разделить соединения так, чтобы для получения таблиц использовалось одно соединение, а для получения строк использовалось другое.
Измените параллелизм в цикле «for each».
По умолчанию итерации цикла «for each» запускаются одновременно до достижения предела по умолчанию. Если у вас есть соединитель, который регулируется внутри цикла «for each», то можно уменьшить количество итераций цикла, выполняемых параллельно. Дополнительные сведения см. в следующих статьях:
Служба или система назначения
Хотя соединитель имеет собственные ограничения регулирования, целевая служба или система, вызванная соединителем, может также иметь ограничения регулирования. Например, некоторые API в Microsoft Exchange Server имеют более широкие ограничения регулирования, чем соединитель Office 365 Outlook.
По умолчанию экземпляры приложения логики и любые циклы или ветви внутри этих экземпляров выполняются параллельно. Это означает, что несколько экземпляров могут одновременно вызывать одну и ту же конечную точку. Каждый из экземпляров не знает о существовании другого, поэтому попытки повторения неуспешных действий могут привести к состоянию гонки, когда несколько вызовов пытаются выполниться в одно и то же время, однако для их успешного выполнения эти вызовы должны поступить в целевую службу или систему до начала регулирования.
Предположим, имеется массив, содержащий 100 элементов. Для просмотра массива используется цикл «for each», и включение контроля параллелизмом цикла позволит ограничить количество параллельных итераций до 20 или до текущего ограничения по умолчанию. Внутри этого цикла действие вставляет элемент из массива в базу данных SQL Server, которая разрешает всего 15 вызовов в секунду. В этом сценарии возникает проблема регулирования, так как скапливается очередь невыполненных попыток повтора и поэтому выполнение не происходит.
В этой таблице описана временная шкала событий, происходящих в цикле, когда интервал повтора действия равен 1 секунде:
| На момент времени | Количество выполненных действий | Количество невыполненных действий | Количество повторных попыток |
|---|---|---|---|
| T + 0 секунд | 20 вставок | 5 ошибок, из-за ограничения SQL | 5 повторов |
| T + 0,5 секунд | 15 вставок, из-за предыдущих 5 попыток в ожидании | Все 15 завершатся ошибкой из-за того, что предыдущее ограничение SQL действует еще 0,5 секунды | 20 повторов (5 предыдущих + 15 новых) |
| T + 1 секунда | 20 вставок | 5 ошибок плюс предыдущих 20 повторов, из-за ограничения SQL | 25 повторов (20 предыдущих + 5 новых) |
Для управления регулированием на этом уровне доступны следующие варианты.
Создайте приложения логики таким образом, чтобы каждое из них обрабатывало единственную операцию.
Продолжая пример сценария SQL Server, приведенный в этом разделе, можно создать приложение логики, которое помещает элементы массива в очередь, например очередь служебной шины Azure. А затем создать другое приложение логики, которое будет выполнять только операцию вставки для каждого элемента в этой очереди. Таким образом, только один экземпляр приложения логики будет выполняться в один момент времени, и либо будет завершена операция вставки и переход к следующему элементу в очереди, либо экземпляр получит ошибку 429 и не будет пытаться выполнять бесперспективные повторы.
Создайте родительское приложение логики, которое вызывает дочернее или вложенное приложение логики для каждого действия. Если родительскому приложению необходим вызов различных дочерних приложений исходя из результата, то можно использовать действие условия или переключателя, определяющее, какое дочернее приложение будет вызываться. Это позволит сократить количество вызовов или операций.
Предположим, есть два приложения логики, каждое с триггером опроса, проверяющим учетную запись электронной почты раз в минуту на конкретную тему, например «Успешно» или «Ошибка». Такая установка производит 120 обращений в час. Если вместо этого создать одно родительское приложение логики, которое тоже будет опрашивать раз в минуту, но вызывать дочернее приложение логики в зависимости от темы «Успешно» или «Ошибка», то в этом случае количество обращений удастся сократить вдвое (до 60 в час).
Настройка пакетной обработки.
Если целевая служба поддерживает пакетные операции, то регулирование можно устранить за счет обработки элементов группами или пакетами. Чтобы реализовать решение пакетной обработки, необходимо создать приложения логики «получатель пакета» и «отправитель пакета». Пакет отправителя собирает сообщения или элементы до тех пор, пока не будут выполнены указанные условия, а затем отправляет эти сообщения или элементы одной группой. Получатель пакета принимает эту группу и обрабатывает содержащиеся в ней сообщения или элементы. Дополнительные сведения см. в разделе Пакетная обработка сообщений в группах.
Используйте версии веб-перехватчика для триггеров и действий, а не опрашивающие версии.
Почему? Опрашивающий триггер продолжает проверять целевую службу или систему через определенные интервалы времени. Очень часто такой интервал, например раз в секунду, может приводить к проблемам регулирования. Однако триггер или действие веб-перехватчика, например HTTP, создает только один вызов целевой службы или системы, который происходит во время подписки и запрашивает, что назначение уведомляет триггер или действие только при наступлении события. Таким образом, триггеру или действию не нужно постоянно проверять назначение.
Таким образом, если целевая служба или система поддерживает веб-перехватчики или имеет соединитель с версией веб-перехватчика, то этот вариант является более предпочтительным, чем использование опрашивающей версии. Чтобы определить триггеры и действия веб-перехватчика, убедитесь, что они имеют тип ApiConnectionWebhook или не требуют указания периодичности. Дополнительные сведения см. в статьях Триггер APIConnectionWebhook и Действие APIConnectionWebhook.
Как исправить ошибку во время выполнения 429
Люди часто предпочитают ссылаться на «ActiveX component can’t create object or return reference to this object» как на «ошибку времени выполнения», также известную как программная ошибка. Когда дело доходит до Windows Operating System, инженеры программного обеспечения используют арсенал инструментов, чтобы попытаться сорвать эти ошибки как можно лучше. К сожалению, многие ошибки могут быть пропущены, что приводит к проблемам, таким как те, с ошибкой 429.
«Creating objects requires that the object’s class be registered in the system registry and that any associated dynamic-link libraries (DLL) be available.» может возникнуть у пользователей Windows Operating System даже при нормальном использовании приложения. Когда это происходит, конечные пользователи могут сообщить Microsoft Corporation о наличии ошибок «ActiveX component can’t create object or return reference to this object». Microsoft Corporation может устранить обнаруженные проблемы, а затем загрузить измененный файл исходного кода, позволяя пользователям обновлять свою версию. Таким образом при выполнении обновления программного обеспечения Windows Operating System, он будет содержать исправление для устранения проблем, таких как ошибка 429.
Почему происходит ошибка времени выполнения 429?
Вполне вероятно, что при загрузке Windows Operating System вы столкнетесь с «ActiveX component can’t create object or return reference to this object». Мы можем определить, что ошибки во время выполнения ошибки 429 происходят из:
Ошибка 429 Crash — ошибка 429 блокирует любой вход, и это может привести к сбою машины. Обычно это происходит, когда Windows Operating System не может распознать, что ему дается неправильный ввод, или не знает, что он должен производить.
Утечка памяти «ActiveX component can’t create object or return reference to this object» — ошибка 429 утечка памяти приводит к увеличению размера Windows Operating System и используемой мощности, что приводит к низкой эффективности систем. Повреждение памяти и другие потенциальные ошибки в коде могут произойти, когда память обрабатывается неправильно.
Ошибка 429 Logic Error — Компьютерная система создает неверную информацию или дает другой результат, даже если входные данные являются точными. Он материализуется, когда исходный код Microsoft Corporation ошибочен из-за неисправного дизайна.
В большинстве случаев проблемы с файлами ActiveX component can’t create object or return reference to this object связаны с отсутствием или повреждением файла связанного Windows Operating System вредоносным ПО или вирусом. Как правило, самый лучший и простой способ устранения ошибок, связанных с файлами Microsoft Corporation, является замена файлов. Помимо прочего, в качестве общей меры по профилактике и очистке мы рекомендуем использовать очиститель реестра для очистки любых недопустимых записей файлов, расширений файлов Microsoft Corporation или разделов реестра, что позволит предотвратить появление связанных с ними сообщений об ошибках.
Типичные ошибки ActiveX component can’t create object or return reference to this object
Частичный список ошибок ActiveX component can’t create object or return reference to this object Windows Operating System:
- «Ошибка программного обеспечения ActiveX component can’t create object or return reference to this object. «
- «Недопустимый файл ActiveX component can’t create object or return reference to this object. «
- «Извините за неудобства — ActiveX component can’t create object or return reference to this object имеет проблему. «
- «К сожалению, мы не можем найти ActiveX component can’t create object or return reference to this object. «
- «Отсутствует файл ActiveX component can’t create object or return reference to this object.»
- «Проблема при запуске приложения: ActiveX component can’t create object or return reference to this object. «
- «ActiveX component can’t create object or return reference to this object не выполняется. «
- «Ошибка ActiveX component can’t create object or return reference to this object. «
- «Неверный путь к программе: ActiveX component can’t create object or return reference to this object. «
Проблемы ActiveX component can’t create object or return reference to this object с участием Windows Operating Systems возникают во время установки, при запуске или завершении работы программного обеспечения, связанного с ActiveX component can’t create object or return reference to this object, или во время процесса установки Windows. Важно отметить, когда возникают проблемы ActiveX component can’t create object or return reference to this object, так как это помогает устранять проблемы Windows Operating System (и сообщать в Microsoft Corporation).
Источник ошибок ActiveX component can’t create object or return reference to this object
Проблемы ActiveX component can’t create object or return reference to this object могут быть отнесены к поврежденным или отсутствующим файлам, содержащим ошибки записям реестра, связанным с ActiveX component can’t create object or return reference to this object, или к вирусам / вредоносному ПО.
В первую очередь, проблемы ActiveX component can’t create object or return reference to this object создаются:
Ошибка сервера 429 (слишком много запросов за единицу времени) #20
При большом количестве последовательных или параллельных запросов к REST API часто возникает ошибка 429 — The user has sent too many requests in a given amount of time .
Экспериментальным путем установлено, что сервис не позволяет выполнять более 2-х одновременных запросов и таймаут между запросами должен быть примерно не менее 250 ms.
Необходимо реализовать встроенную очередь запросов, которая будет учитывать описанные выше ограничения.
The text was updated successfully, but these errors were encountered:
wmakeev commented Nov 24, 2015
Спасибо, за информацию! Жалко что официально не публикуется. Проверю и приму в работу.