Что значит слишком много запросов

Как исправить ошибку HTTP 429: причины и способы устранения [Новости MiniTool]

How Fix Http Error 429

Резюме :

Ошибка HTTP 429 часто возникает на устройстве пользователей; за ним часто следует сообщение: Слишком много запросов. Это предотвратит доступ пользователей к определенной странице и просмотр необходимой им информации. Внимательно прочтите следующее содержимое, чтобы понять, что означает HTTP 429 и как решить проблему различными способами.

Ошибка HTTP 429: слишком много запросов

Многие пользователи сообщали об одной и той же проблеме: они сталкивались с Ошибка HTTP 429 при попытке получить доступ к определенной странице через веб-браузер: например, Microsoft Edge, Google Chrome и Firefox. А за кодом состояния 429 часто следует сообщение об ошибке — слишком много запросов — что не позволяет им получить доступ к определенной информации. (Вам лучше обратиться к Решение MiniTool для хорошей защиты ваших данных.)

429 слишком много запросов в Google Chrome:

429. Это ошибка.

Сожалеем, но вы недавно отправили нам слишком много запросов. Пожалуйста, повторите попытку позже. Это все, что мы знаем.

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

Люди хотят решить проблему, но не знают, как это сделать, потому что информации не так много. В следующем содержании этой страницы я сначала расскажу о причине HTTP 429; Затем я покажу вам подробные инструкции, как исправить ошибку 429 самостоятельно.

Прочтите эту страницу, если вы столкнулись с ошибкой HTTP 404, не найденной:

Ошибка 404 не найдена, как ее исправить

Ошибка 404 не найден не позволит вам получить доступ к нужному контенту. Важно понять, что происходит и как это исправить.

Причина ошибки 429

Ваша программа может перестать работать, а ваш сервер может замедлиться при обнаружении ошибки HTTP 429. Существуют разные типы кодов ошибок, указывающих на одну и ту же проблему 429.

• 429 Ошибка
• HTTP 429
• Слишком много запросов
• 429 Слишком много запросов
• Ошибка 429 (слишком много запросов)

Все в порядке, пока вы не увидите 429 ответов об ошибках от API. Он говорит, что вы сделали слишком много запросов, достигнув предела скорости API. Ошибка HTTP 429 на самом деле является кодом состояния HTTP; это ошибка клиента, которая отправляется обратно с сервера, чтобы сообщить пользователям, что они достигли допустимого предела скорости.

Ошибка 429 — ужасный опыт, но это не значит, что ограничение скорости — это плохо. Напротив, этот предел велик; он может защитить большинство используемых API от преднамеренного и случайного злоупотребления услугами. Вы должны знать, что ограничения скорости широко используемых API, включая Twitter и Instagram, строже, чем другие.

Как исправить 429 слишком много запросов в Google Chrome

Эта часть покажет вам, как устранить ошибку 429 в браузере Google Chrome, очистив кеши и историю браузера.

1. Дважды щелкните значок приложения на рабочем столе, чтобы открыть Google Chrome. (Вы также можете открыть его, дважды щелкнув исполняемый файл в папке установки или выбрав Google Chrome в меню «Пуск».)
2. Найдите вариант с тремя точками в правом верхнем углу открытия Chrome; он используется для настройки и управления Google Chrome.
3. выберите Настройки из раскрывающегося меню (это третий вариант снизу).
4. Прокрутите вниз, чтобы найти Конфиденциальность и безопасность (Вы можете перейти туда напрямую, нажав Конфиденциальность и безопасность на левой боковой панели.)
5. Щелкните по первому варианту: Очистить данные просмотра (очистить историю, файлы cookie, кеш и т. Д.) .
6. Убедитесь, что Базовый вкладка выбрана вверху.
7. Проверьте Файлы cookie и другие данные сайта и Кешированные изображения и файлы .
8. Нажми на Очистить данные кнопку в правом нижнем углу и дождитесь завершения действия.

Если этот метод не помог, вы можете попробовать следующие шаги: прокрутите вниз в окне настроек -> нажмите на Продвинутый кнопку, чтобы увидеть раскрывающиеся параметры -> перейдите к Сброс и очистка раздел -> попробовать Восстановить исходные настройки по умолчанию или же Очистить компьютер характерная черта.

Если вам нужно восстановить удаленную историю в Google Chrome после исправления ошибки HTTP 429, следуйте этому руководству:

Как восстановить удаленную историю в Google Chrome — полное руководство

Есть 8 эффективных методов, рассказывающих вам, как самостоятельно восстановить удаленную историю в Google Chrome.

Источник

Решение проблем регулирования (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.

Источник