Лимит запросов за сеанс что это

Превышено ограничение количества запросов за сутки в ВК — что делать с ошибкой

Потеряв пароль от ВК его всегда можно получить обратно через восстановление, введя свой номер телефона. Но ошибка «Превышено ограничение количества запросов за сутки» может не позволить это сделать. Она может появиться даже при первой попытке ввести номер, что очень удивительно. Если у вас не привязана почта, через которую, в принципе, можно решить эту проблему, тогда данная статья вам поможет.

Причина ограничения

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

Ошибка «Превышено ограничение количества запросов за сутки» в ВК

Что делать для восстановления

Итак, если вы забыли свой пароль и не можете его восстановить из-за данного лимита, тогда стоит попробовать следующее.

Дождаться истечения бана

Ожидание в несколько дней помогает обойти блокировку по превышению лимита. Блокировка выдается на 24 часа. Поэтому выждав такое время, пользователю разблокируют номер телефона. На удивление бывают случаи, когда бан не снимается и после суток. В таком случае следует проверить другие моменты.

IP-адрес

Блокировка произошла по вашему IP. Тут нужно его сменить. Зайдите в ВК с другого ПК, попробуйте вариант с телефоном или установите программу VPN. Главное протестируйте как можно больше вариантов и не останавливайтесь на первом же провале.

Использование программы HideGuard VPN

Ошибка сервера

Всем известны случаи падения серверов ВК, когда даже фотографии и история сообщений не загружаются. Возможно в этот раз проблема с восстановлением пароля по номеру телефона. Но, кроме как подождать, попробуйте повторить свою попытку не в вечернее время. Скажем, рано утром. Это частично избавит социальную сеть от миллионов людей и тем самым снимет нагрузку с сервера.

Приложения и браузер

Если ошибка «Превышено ограничение количества запросов за сутки» появляется в каком-то приложении на телефоне или ПК, то просто замените этот софт другим. Установите утилиту от другого производителя, смените браузер. Лучше загружать только лицензионный софт из маркетов или официальных сайтов.

Написать в техподдержку

Если страницу вы не можете восстановить, тогда пишите на их почту support@vk.com. Можно задать вопрос с другого активного аккаунта, но нужно четко уточнить причину такого шага — например, «вы не разбираетесь в тонкостях настроек восстановления, и решили написать от другого пользователя». Обращаться нужно через соответствующую форму на сайте ВК. Для этого внизу левого меню кликните по пункту «Еще». В выдвинувшемся списке отыщите «Помощь». Самым последним вариантом будет виднеться «Мои вопросы». Справа нужная вам графа – Новый вопрос. Но учтите, что ответ может поступить не раньше суток, а ожидание может доходить до нескольких дней. Желательно сразу все подробно описать, указав свои данные.

Пример запроса в службу поддержки ВКонтакте

Источник

Как жить с ограничениями внешних API на количество запросов

Многие сервисы предоставляют возможность взаимодействовать с ними не только обычным пользователям через отточенные и оптимизированные графические интерфейсы, но и внешним разработчикам из своих программ через API. При этом сервисам важно контролировать нагрузку на свою инфраструктуру. В ситуации с обычными пользователями большинство проблем с нагрузкой не возникнет из-за контроля кода приложения, отправляющего запросы к сервису, со стороны разработчиков сервиса (пользователей, пытающихся что-то делать в приложении за рамками предложенных разработчиками интерфейсов и задокументированных возможностей, мы в данной статье не рассматриваем). В случае же со внешними разработчиками простор для создания нагрузки на сервис ограничен только фантазией этих самых внешних разработчиков. Чтобы немного ограничить этот простор, стала распространена практика введения ограничений на количество запросов в единицу времени к API сервиса.

Мы уже рассказывали о том, как можно реализовать эти ограничения, если вы сами разрабатываете API сервиса, сегодня хотим рассказать о том, как жить с «клиентской» стороны и удобно пользоваться ограниченным по количеству запросов API.

Вводные данные

Меня зовут Юрий Гаврилов, я работаю в команде Data Platfrom в ManyChat. У нас в компании есть маркетинговый отдел, который, среди всего прочего, любит общаться с нашими клиентами через сервис Intercom, позволяющий отправлять удобные In-App сообщения пользователю прямо в нашем веб-приложении. Чтобы эти коммуникации были осмысленными, Intercom должен получать некоторую информацию о наших клиентах (имя, дату регистрации, различные простые метрики их аккаунтов и т.д.). За предоставление этих данных в Intercom отвечает наш довольно-таки монолитный бекенд-компонент, хранящий информацию о наших пользователях. А ещё, совсем недавно, мы построили классный аналитический контур (о котором обязательно расскажем в следующих статьях), также хранящий кучу информации о наших пользователях, и довольно изолированный от упомянутого выше бекенд-компонента. В этом контуре аналитики обсчитывают более сложные пользовательские метрики, гоняют ML-алгоритмы и хранят витрины с результатами всех этих вычислений. Для ещё более крутых коммуникаций с клиентами, часть из этих результатов также хотелось бы иметь в Intercom.

И тут мы сталкиваемся с проблемой: есть разные, изолированные друг от друга компоненты, желающие делать вызовы внешнего API с довольно сильным ограничением в 1000 запросов в минуту. При этом, ограничение применяется в рамках всего аккаунта Intercom, а не рассчитывается индивидуально для каждого компонента.

Мысли о решении проблемы вслух

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

Из-за этого сразу же приходят мысли, что нам нужна «единая точка общения» с этим API, которая будет непосредственно обращаться к API, контролировать исчерпание лимитов и управлять логикой по приоритизации взаимодействия с API. К этой точке, в свою очередь, должны обращаться все желающие взаимодействовать с API компоненты.

Реализация «единой точки общения»

Мы уже говорили, что в ManyChat любят Redis — он же нам помог для решения и этой задачи. Для создания такой «единой точки» нужно где-то собирать информацию о том, какие именно методы хотят вызвать во внешнем API наши компоненты. Если внешние компоненты захотят вызвать методов больше, чем позволено ограничениями API, на момент «передышки», пока не обновятся лимиты, эту информацию нужно где-то хранить. А ещё, нам бы очень хотелось ввести систему приоритетов, чтобы «базовые» данные, которые бекенд-компонент хочет отправить в Intercom, не ждали, пока прогрузится много «продвинутых» данных из аналитического контура.

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

На каждый приоритет нам нужно создать по своей очереди, в которую компоненты будут записывать свои намерения вызвать тот или иной метод в API, а один общий consumer будет в порядке приоритетности эти очереди вычитывать и непосредственно вызывать методы API. Если при вызове очереди он сталкивается с достижением rate-limit, он подождет, пока лимиты сбросятся, и продолжит работу.

В нашем случае очереди нужно две — для «базовых» данных из бекенд-компонента (давайте назовем её BackendQueue), и менее приоритетных «продвинутых» данных из аналитического контура (AnalyticsQueue). Прелесть такого подхода заключается также и в том, что совершенно не важно, на каких языках программирования написаны компоненты и consumer, все они смогут выполнять свою работу, нужно только определиться с форматом хранящихся в очереди данных.

Давайте для определенности и простоты примем в этой статье такой формат (JSON):

Тогда MVP нашего consumer’a может выглядеть так (PHP)

Здесь мы разбираем очереди в порядке приоритетов, при получении информации о методе пытаемся его выполнить, если сталкиваемся с лимитами — ждем и пытаемся снова ограниченное количество раз.

А наши компоненты на разных языках программирования могут отправлять запрос на вызов интересующего их метода:

Аналитический контур (Python):

Проблемы метода и их решения

Однопоточность → немасштабируемость

Когда мы попытались перейти на такую систему — всё заработало, данные доходили до Intercom, лимиты не исчерпывались. Но возникла другая проблема — каждое обращение к внешнему сервису занимает какое-то время, и когда все вызовы API «сместились» в один поток, мы совсем перестали доходить до rate-limit, перформанс customer’a был в несколько раз меньше rate-limit’ов, и стало понятно, что нужно всю эту радость как-то распараллеливать. Redis вполне безопасно (в смысле параллельности) позволяет разбирать свои очереди нескольким consumer’ам. В целом, нет никакой проблемы в том, чтобы запустить несколько consumer’ов, описанных выше, на одни и те же очереди и проблемы не будет. Каждый из них будет точно так же с соблюдением приоритетности разбирать очередь и, при превышении лимитов, ждать, пока внешний сервис сбросит лимит, и далее работать снова до исчерпания лимита.

Но мы решили немного ограничить вызовы с нашей стороны, потерять несколько десятков возможных вызовов в пределах лимитов, и не доводить consumer’ов до ситуации, когда внешний сервис сообщает им о достижении лимита вызовов. Для этого мы рассчитали для каждого consumer’а его собственный лимит на количество вызовов в единицу времени, при достижении которого он перестает разбирать очередь и делать вызовы к API до перехода к следующему временному интервалу.

Пример самоконтролирующего лимиты consumer’a (PHP)

Одностороннее взаимодействие с API

Иногда бывает нужно не только вызвать какой-то метод во внешнем API, но и получить и обработать его ответ. Мы же перевели наше взаимодействие компонентов с API в асинхронный формат. Проблема получения ответа от сервера и доведения его до исходного компонента — решаемая. Достаточно дополнить данные о методе, который мы хотим выполнить, данными о callback’e, который consumer’у необходимо выполнить при получении ответа от внешнего сервиса. Мы написали несколько стандартных callback’ов, которые складывают полученные ответы в определенные очереди, из которых компоненты могут их прочитать и обработать самостоятельно.

Внедрение такой структуры взаимодействия, безусловно, менее удобное, чем стандартные блокирующие вызовы методов и получение ответа сразу, но обойтись без такой жертвы нам не удалось.

Что делать, когда запросов становится настолько много, что очереди разгребаются часами/днями/неделями?

Здесь мы точно не волшебники, и запрограммировать свое взаимодействие с внешним API так, чтобы превышать его rate-limit, мы точно не можем. По задачам загрузки данных наших клиентов мы внедрили у себя систему по учету тех данных, что уже были отправлены во внешний сервис. Когда наступает очередная выгрузка данных о пользователях, отправляются только данные о тех пользователях, которые обновились, и, тем самым, уменьшается необходимое количество запросов.

В остальном, в данной ситуации не остаётся ничего иного, кроме как разговаривать со внешним сервисом на тему увеличения лимита запросов.

Заключение

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

Надеюсь, что кому-нибудь такой подход окажется полезным и интересным. Буду рад ответить на вопросы в комментариях и узнать, какие подходы для взаимодействия с ограниченными по количеству запросов API используете вы.

Источник

Ограничения на запросы и распределение запросов

Как первоначально анонсировано в октябре 2019 года, есть ограничения запросов Power Platform, чтобы помочь обеспечить уровни обслуживания, доступность и качество платформы. Есть ограничения на количество запросов, которые пользователи могут отправлять каждый день через Power Apps, Power Automate, Power Virtual Agents и приложения Dynamics 365.

Что такое запрос Microsoft Power Platform?

Запросы в Microsoft Power Platform состоят из различных действий, которые пользователь выполняет с разными продуктами. На высоком уровне ниже показано, что составляет запрос API:

Для Dataverse существует небольшой набор внутренних системных операций, которые исключены из ограничений, такие как вход в систему, выход из системы и операции с системными метаданными.

В разделах ниже описаны типы запросов и ограничения, установленные для каждого из них.

Лимиты запросов лицензированных пользователей

Все пользователи Microsoft Power Platform имеют ограничения на количество запросов в зависимости от назначенной им лицензии. В следующей таблице указано количество запросов, которые пользователь может сделать за 24 часа:

1 В эту категорию входят платные лицензии для плана Power Apps на пользователя (который включает предыдущие лицензии плана 1 Power Apps и плана 2 Power Apps), план Power Automate на пользователя (который включает предыдущие лицензии плана 1 Power Apps и плана 2 Power Apps), Dynamics 365 Sales Premium, Dynamics 365 Sales Enterprise, Dynamics 365 Sales Professional, Dynamics 365 Customer Service Enterprise, Dynamics 365 Customer Service Professional, Dynamics 365 Field Service, Microsoft Relationship Sales, Microsoft Industry Cloud, Dynamics 365 Project Service Automation, Dynamics 365 Commerce, Dynamics 365 Human Resources, Dynamics 365 Finance, Dynamics 365 Project Operations, Dynamics 365 Supply Chain Management, план Dynamics 365 Customer Engagement, план Dynamics 365 Unified Ops, план Dynamics 365, Dynamics 365 for Operations Device, Dynamics 365 for Operations Activity, Dynamics AX Online Device, Dynamics AX Online Task, Dynamics CRM Online Enterprise, и Dynamics CRM Online Professional.

2 В эту категорию входят план Power Apps с оплатой по мере использования и платные лицензии плана Power Apps на приложение, Dynamics 365 Team Member, Dynamics CRM Online Basic, Dynamics CRM Online Essential, Dynamics AX Self-Serve, лицензии Microsoft 365 и Microsoft Project Online (план 1, план 3 и план 5). См. Приложение B в Руководстве по лицензированию для лицензий Microsoft 365, которые включают возможности Power Apps и Power Automate.

3 В плане Power Automate на поток позволяет специально зарезервировать мощность для одного потока, независимо от владельца потока. При этом не используются лимиты запросов нелицензированных пользователей на уровне клиента.

4 Запросы Power Virtual Agents считаются от потоков Power Automate, инициированных из чат-ботов Power Virtual Agents. Пакет начальных сеансов Power Virtual Agents и пакет дополнительных сеансов получают одни и те же ежедневные лимиты запросов Power Platform.

Прочие сведения

Ограничения запросов Power Platform включены только в платные базовые лицензии в модели лицензирования Dynamics 365 «базовая + прикрепленная». Прикрепленные лицензии не включают отдельных ограничений. Например, если у пользователя есть лицензия Dynamics 365 Customer Service Enterprise в качестве базовой лицензии и лицензия Dynamics 365 Sales Enterprise как прикрепленная лицензия, то общий лимит запросов будет = базовая лицензия – Dynamics 365 Customer Service Enterprise.

Если пользователю назначено несколько платных лицензий, общее количество разрешенных запросов будет равно сумме запросов, разрешенных для каждой лицензии. Например, если у пользователя есть как базовая лицензия Dynamics 365 Customer Service Enterprise, так и лицензия Power Apps на пользователя, тогда у этого пользователя будет в общей сложности 40 000 + 40 000 = 80 000 запросов, доступных за 24 часа.

Запросы Power Virtual Agents считаются от потоков Power Automate, инициированных из чат-бота Power Virtual Agents. Пакет начальных сеансов Power Virtual Agents и пакет дополнительных сеансов получают одни и те же ежедневные лимиты запросов Power Platform.

Лимиты запросов нелицензированных пользователей

Отдельный лимит установлен для определенных действий (например, фоновый процесс, который переносит данные между базами данных), которые не требуют взаимодействия пользователя со службой. Эти ограничения определяются и объединяются на уровне арендатора. Dataverse позволяет иметь удостоверения, не требующие взаимодействия со службой какого-либо пользователя. Сюда входит следующее:

Дополнительно есть специальные бесплатные ($0) лицензии, которые используются для взаимодействия с приложениями Dynamics 365, такими как Dynamics 365 Marketing. Дополнительные сведения см. Как лицензируется Marketing.

Для этих нелицензионных удостоверений каждый клиент получит начальный базовый лимит запросов для каждого клиента, определяемый тем, какие платные лицензии есть у клиента, плюс накопленные лимиты, определяемые количеством оплаченных лицензий Dynamics 365 Enterprise и Professional. 1 Этот пул могут использовать только эти нелицензированные пользователи, но не пользователи с назначенными интерактивными пользовательскими лицензиями.

1 В эту категорию входят лицензии для Dynamics 365 Sales Premium, Dynamics 365 Sales Enterprise, Dynamics 365 Sales Professional, Dynamics 365 Customer Service Enterprise, Dynamics 365 Customer Service Professional, Dynamics 365 Field Service, Microsoft Relationship Sales, Dynamics 365 Project Service Automation, Dynamics 365 Commerce, Dynamics 365 Human Resources, Dynamics 365 Finance, Dynamics 365 Project Operations, Dynamics 365 Supply Chain Management, план Dynamics 365 Customer Engagement, план Dynamics 365 Unified Ops, план Dynamics 365, Dynamics CRM Online Enterprise и Dynamics CRM Online Professional. Начисленные ограничения запросов на уровне клиента без лицензий Power Platform включены только в платные базовые лицензии в модели лицензирования Dynamics 365 «базовая + прикрепленная».

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

Дополнительные сведения

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

Если у клиента есть несколько типов подписок, его объем запросов нелицензированных пользователей будет использовать подписку линейки продуктов с большим количеством запросов. Например, если у клиента есть как подписки на базовую лицензию Dynamics 365 Customer Service Enterprise (минимум 500 000 запросов + начисленные лимиты), так и подписки Power Apps на пользователя (25 000 запросов в день), их объединенная емкость запросов на уровне клиента будет составлять минимум 500 000 запросов + начисленные лимиты на 24 часа.

Что произойдет, если лицензированный или нелицензированный пользователь превысит лимиты

Лимиты запросов Power Platform были обновлены и существенно увеличены в конце 2021 года до уровней, которые значительно превышают типичное использование для большинства клиентов. Ожидается, что с обновленными лимитами очень немногие пользователи превысят задокументированные лимиты. Если вы ожидаете превышения лимитов для нелицензированных пользователей, обратитесь к своему торговому посреднику или в группу по работе с клиентами Microsoft, чтобы обсудить индивидуальное решение.

Любые возможные принудительные меры по интенсивному использованию не будут внедрены раньше, чем через шесть месяцев после того, как отчет об использовании запросов Power Platform будет доступен в центре администрирования Power Platform. Ожидается, что отчеты администраторов появятся в первом квартале календарного 2022 года.

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

Увеличение объема Power Apps и Power Automate

Клиенты, которые отмечают в отчетах, что они часто используют больше запросов, чем лимиты, могут избежать принудительной реакции, купив надстройку емкости Power Apps и Power Automate. Эта надстройка позволяет клиентам увеличивать лимиты для определенных пользователей с высокой степенью использования с лицензией или пользователей без лицензии с высоким уровнем использования. Каждая надстройка емкости увеличивает запросы еще на 50 000 за 24 часа. Для увеличения лимитов можно назначить несколько надстроек емкости.

В настоящее время надстройки емкости не могут быть назначены пользователям (включая пользователей приложений, администраторов и неинтерактивных пользователей). Функциональные возможности для назначения надстроек емкости будут согласованы со сроками принудительного применения высокой загрузки.

Другие применимые ограничения

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

Просмотрите следующие ресурсы для получения информации о существующих ограничениях защиты службы для каждой службы:

Вопросы и ответы

Какие инструменты я могу использовать для мониторинга и анализа запросов Power Platform на платформе?

Отчетность для использования запроса Power Platform будет в центре администрирования Power Platform, когда он станет общедоступным, это ожидается в первом квартале 2022 года. Первоначально эта отчетность будет в формате Excel для загрузки с ежедневными отчетами об использовании запросов в сравнении с ограничениями.

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

Дополнительно для специального использования Power Automate вы можете увидеть использование действия для данного потока, выбрав действие Аналитика со страницы свойств потока, и это работает для всех типов действий.

Каковы сроки для лимитов запросов Power Platform?

Концепция лимитов была впервые представлена в конце 2019 года, а задокументированные лимиты были существенно увеличены в конце 2021 года. Общедоступная отчетность для запросов Power Platform ожидается в первом квартале 2022 календарного года. Любое потенциальное принудительное применение с высоким уровнем использования начнется не раньше, чем через шесть месяцев после того, как будут опубликованы отчеты. Присвоение дополнительных пакетов емкости должно быть согласовано с требованиями к интенсивному использованию.

Какие лимиты учетной записи используются для классических рабочих процессов или потоков Power Automate?

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

Переносятся ли лимиты запросов Microsoft Power Platform со дня на день или с месяца на месяц?

№ Все запросы Microsoft Power Platform существуют 24 часа. Если они не потребляются, они не переносятся на следующий день и не накапливаются в течение месяца.

Получает ли каждый пользователь приложения, неинтерактивный пользователь, административный пользователь или пользователь СИСТЕМЫ собственное ограничение уровня клиента?

Нет. Ограничения уровня клиента являются общими для всех пользователей приложений, неинтерактивных пользователей, административных пользователей или пользователя СИСТЕМЫ в пределах клиента.

Учитываются ли запросы, сгенерированные из классических рабочих процессов или подключаемых моделей Dataverse в Dataverse, в лимитах запросов?

Да, если эти запросы выполняют запросы типа CRUD, назначения или общего доступа, они будут считаться. В случае классических рабочих процессов это включает в себя такие действия, как проверка условий, запуск дочерних рабочих процессов или остановка рабочих процессов. Однако запросы, созданные внутри платформы, не учитываются, например: sdkmessagerequest, solutioncomponentdefinition и ribbonclientmetadatareporting.

Следует ли использовать сторонний инструмент интеграции данных вместо Power Automate, чтобы не выйти за пределы моих лимитов?

Нет, на сторонние инструменты интеграции данных распространяются те же ограничения, что и на запланированные, мгновенные или автоматические потоки. Таким образом, нет никакой разницы, решите ли вы использовать Power Automate или сторонний инструмент. Более того, запросы от Power Automate к Dataverse не учитываются дважды, поток, вызывающий одно действие, будет считаться только одним запросом при учете его лимита, а не двумя.

Источник