Rate limited что значит
rate limit
Смотреть что такое «rate limit» в других словарях:
rate limit — rate restriction, instruction to buy or sell securities only within a set range of prices; restrictions on price ranges … English contemporary dictionary
rate-cap — rate caps, rate capping, rate capped 1) VERB: usu passive In Britain, when a local council was rate capped, the government prevented it from increasing local taxes called rates, in order to force the council to reduce its spending or make it more … English dictionary
rate-capping — rateˈ capping noun The setting by central government of an upper limit on the rate that can be levied by a local authority • • • Main Entry: ↑rate … Useful english dictionary
rate cap — ˈrate cap f2 [rate cap] noun (in the US) a limit placed on the amount of interest banks, etc. may charge … Useful english dictionary
Limit (mathematics) — This is an overview of the idea of a limit in mathematics. For specific uses of a limit, see limit of a sequence and limit of a function. In mathematics, the concept of a limit is used to describe the value that a function or sequence approaches… … Wikipedia
Rate of convergence — In numerical analysis, the speed at which a convergent sequence approaches its limit is called the rate of convergence. Although strictly speaking, a limit does not give information about any finite first part of the sequence, this concept is of… … Wikipedia
limit — lim|it1 [ lımıt ] noun count *** 1. ) the largest or smallest amount or the highest or lowest level of something that is allowed: speed/spending limits limit on: There are strict limits on presidential power. limit to: There has to be a fair… … Usage of the words and phrases in modern English
limit */*/*/ — I UK [ˈlɪmɪt] / US verb [transitive] Word forms limit : present tense I/you/we/they limit he/she/it limits present participle limiting past tense limited past participle limited 1) to prevent a number, amount, or effect from increasing past a… … English dictionary
limit — limitable, adj. limitableness, n. /lim it/, n. 1. the final, utmost, or furthest boundary or point as to extent, amount, continuance, procedure, etc.: the limit of his experience; the limit of vision. 2. a boundary or bound, as of a country, area … Universalium
Rate function — In mathematics mdash; specifically, in large deviations theory mdash; a rate function is a function used to quantify the probabilities of rare events. It is required to have several nice properties which assist in the formulation of the large… … Wikipedia
rate — 1. n. & v. n. 1 a stated numerical proportion between two sets of things (the second usu. expressed as unity), esp. as a measure of amount or degree (moving at a rate of 50 miles per hour) or as the basis of calculating an amount or value (rate… … Useful english dictionary
Celery throttling — настраивам rate limit для очередей
В этой статье я покажу как решить одну из проблем, возникающих при использовании распределенных очередей задач — регулирование пропускной способности очереди, или же, более простым языком, настройка ее rate limit’a. В качестве примера я возьму python и свою любимую связку Celery+RabbitMQ, хотя алгоритм, который я использую, никак не зависит от этих инструментов и может быть реализован на любом другом стэке.
So what’s the problem?
Для начала пара слов о том, какую проблему я вообще пытаюсь решить. Дело в том, что 99.9% сервисов в интернете запрещают бесконтрольно закидывать их сотнями/тысячами запросов в секунду, угрожая дать в ответ какой-нибудь 403 или 500. Нет, ну правда, жалко им чтоле? Иногда таким сервисом может выступать даже своя собственная БД… Вобщем, доверять нынче нельзя никому, поэтому приходится себя как-то сдерживать.
Конечно, если вся работа ведется внутри 1го процесса, то никакой проблемы нет, но т.к мы работаем с Celery, то у нас может быть не только N процессов (далее воркеров), но и M машин, и задача все это дело синхронизировать уже не кажется столь тривиальной.
What’s in the box
Нельзя задать rate limit на группу задач.
Это неудобно, т.к зачастую доступ к какому-то лимитированому ресурсу размазан между разными тасками.
Этот лимит работает только внутри воркера, то есть он локальный и у каждого воркера свой.
Конечно, можно еще раз поделить лимит, теперь взяв в расчет еще и количество воркеров. Но все это начнет работать дико неэффективно, если таски будут прилетать неравномерно, например в какую-то минуту мы получим 60 вызовов get_github_api1() и 0 вызовов get_github_api2() — будут выполнены только 30 вызовов первого типа, хотя могли бы быть все 60. К тому же каждый раз, как появится новая таска, которой нужен доступ к этому ресурсу, придется снова везде пересчитывать все лимиты. Вобщем фича конечно полезная, но только для самых простых вариантов.
Bringing decision
Token Bucket
Решением проблемы для меня стал Token Bucket — алгоритм, использующийся для контроля полосы пропускания канала в компьютерных и телекомуникационных сетях. Опишу его в 2ух словах: пакет данных, чтобы пройти проверку канала на лимит, должен иметь при себе токен, который он взял из хранилища; в то же время в хранилище токены поступают с некоторой частотой. То есть пропускная способоность канала ограничивается скоростью выпуска токенов, которую нам и надо регулировать.
В нашем же случае вместо пакета данных мы имеем таску, а хранилищем токенов будут выступать очереди RabbitMQ.
Wrting some code
Чтож, приступим к написанию кода. Создадим файл main.py и зададим базовые настройки:
Не забудьте развернуть Rabbit, я предпочитаю делать это 1ой строчкой докера:
После этого в консоли раз в секунду начнут появляться сообщения:
Отлично, мы наладили выпуск токенов для нашего ‘ведра’. Осталось только научить наших воркеров из него брать. Попробуем оптимизировать код, который мы написали ранее для запросов в github. Добавим эти строчки к main.py :
А теперь проверим, как это все работает. В дополнение к уже запущенному beat добавим 8 воркеров:
И создадим отдельный маленький скрипт для запуска этих задач, назовем его producer.py :
Несмотря на то, что у нас целых 8 рабочих процессов, таски выполняются примерно раз в секунду, отправляясь в конец очереди, если на момент их выполнения не оказалось токена. Также, я думаю, вы уже заметили, что на самом деле мы накладываем rate limit не совсем на очередь, а скорее на какую-то логически связанную группу задач, которые на самом деле могут находится как в разных очередях, так и в одной. Таким образом наш контроль становится даже более детальным и гранулированным.
Putting it all together
Конечно, количество таких групп задач не ограничено (разве что возможностями брокера). Соберем весь код в кучку, расширим и причешим его:
Таким образом суммарные вызовы задач группы google не превысят 100/мин, а группы github — 60/мин. Заметьте, что для того, чтобы настроить такой throttling, понадобилось меньше 50 строк. Как по мне, достаточно просто.
Moving further
Ну, вот все и работает как надо, причем без каких-либо сторонних примочек, средствами только самого брокера. Но зачем останавливаться на достигнутом ;)? Грамотно используя данный алгоритм, можно пойти дальше и создать намного более сложные и гибкие стратегии. Например, некоторые таски могут брать не 1, а несколько токенов (возможно даже из разных очередей, если обращение идет к нескольким сервисам), таким образом у нас появится понятие ‘веса’ задачи, или же расширить размер нашего ‘ведра’ токенов, позволив им накапливаться, тем самым компенсируя периоды простоя. Вобщем, пространство для маневра просто огромное и ограничено только вашим воображением и инженерными навыками) Всем спасибо, всем удачи!
Ограничиваем скорость на маршрутизаторе Cisco. Технология rate-limit
Rate-limit команда вводится в режиме конфигурирования физического интерфейса и имеет следующий синтаксис:
rate-limit input|output [access-group [rate-limit] acl-index] [limit-bps] [nbc] [ebc] conform-action [action] exceed-action [action]
Далее идут три значения скорости limit bps, nbc, ebc
Для расчета всех значений используем такую формулу:
Теперь давайте посмотрим на практике. Возьмем GNS3, один маршрутизатор и две виртуальные машины.
Топология простейшая, чтобы просто показать как это работает.
Ограничим весь трафик из сети 192.168.40.0/24 в сеть 192.168.78.0/24. Для этого на R1 создаем ACL.
Ограничиваем абсолютно весь трафик. Пример простой, могут быть более сложные ACL, чтоб ограничивать скорость по каким-то сервисам, портам и пр.
Проверим скорость в сети до ограничений.
На хосте C1 у нас работает FTP-сервер, С2 — будет ftp-клиентом. Скорость виртуальной сети у меня 1Мбит/c
Видим что скорость закачки около 1Мбит/c.
После этого вешаем на физический интерфейс rate-limit, который смотрит в сеть 192.168.40.0/24
Теперь мы ограничили скорость до 8Кбайт/сек. Проверяем.
Как решить ошибку You are being rate limited в Дискорде
Дискорд – это проект, который был разработан в 2015 году, но смог собрать пользователей, которые смогли оценить достоинства функционала программы. Пользователи могут создавать серверу, и каналы, и добавлять участников, чтобы общаться на выбранную тему. Пользователи могут присоединяться к созданным каналам, и использовать вложенные в программу опции и инструменты. Программа помогает отправлять сообщения, и использовать голосовые каналы. При помощи мессенджера клиенты могут совершать аудиозвонки, или видеоконференции. Разработчики программы регулярно развивают и обновляют мессенджер, чтобы оптимизировать работу. В случае возникновения проблемы, или ошибки пользователям предлагают варианты исправления.
Как переводится такое сообщение?
При работе с программой пользователи могут получить сообщение «You are being rate limited». Фраза означает, что произошла ошибка в приложении, которая требует исправления. Если рассматривать буквальный перевод, то выражение «You are being rate limited» можно перевести, что вы ограничены в скорости действия. Если рассматривать смысл ситуацию, пользователь не может производить необходимое действие в программе Дискорд. Ошибка может выйти при нарушении работы приложения.
Если вы ограничены в скорости действия, это означает, что вы пробовали это действие много раз за короткий промежуток времени, поэтому вам нужно будет дождаться истечения этого таймера ограничения скорости, прежде чем разрешат повторить попытку. К сожалению, нет точного определения для периода тайм-аута. Как правило, ошибка не длится большой период времени, но при нарушении работы на платформе, ошибка может затянуться, и мешать стандартному варианту выполнения работы в программе Дискорд. Например, при прохождении процедуры регистрации, пользователи могут постараться ввести предложенный код несколько раз, и поэтому программа выдаст ошибку. Сложность может возникнуть и по идентичной причине.
Для решения проблемы можно воспользоваться универсальными советами. Пользователи могут не производить действий, поскольку ошибка может исчезнуть без манипуляций со стороны пользователя. Ошибка возникает у начинающих пользователей, или опытных юзеров в программе Дискорд.
Как решить проблему?
Как правило, ошибка варианта «You are being rate limited» пропадает по истечению конкретного момента времени. При этом, нельзя точно определить время, когда ошибка не дает работать на платформе. Решить проблему не получится, следует подождать, и программа начнет работать, после чего и пользователь сможет производить необходимые действия.
Если не удалось дождаться, когда ошибка решиться, следует попробовать перезапустить программу. Для этого, следует выйти из приложения с персонального компьютера, или мобильного устройства, Затем войти снова в программу. Как правило, ошибка должна пропасть, и тогда пользователь сможет продолжить работу.
Если не помогло, то следует принимать кардинальные действия, и переходить к перезапуску устройства. Для этого, следует выключить используемое устройство, смартфон или персональный компьютер. После выключения устройства, программа должна обновиться, и ошибка не будет выявляться. После включения устройства, можно войти в мессенджер Дискорд, и проверить исчезла ли ошибка, и можно ли пользователю производить необходимые действия.
Следует отметить, что выданная ошибка не влияет на стандартный вариант работы программы, и исправление ситуации поможет пользователю продолжать использовать программу Дискорд.
Ограничение скорости обработки запросов в nginx
Фотография пользователя Wonderlane, Flickr
NGINX великолепен! Вот только его документация по ограничению скорости обработки запросов показалась мне, как бы это сказать, несколько ограниченной. Поэтому я решил написать это руководство по ограничению скорости обработки запросов (rate-liming) и шейпингу трафика (traffic shaping) в NGINX.
В дополнение я создал GitHub-репозиторий и Docker-образ, с которыми можно поэкспериментировать и воспроизвести приведенные в этой статье тесты. Всегда легче учиться на практике.
Директивы NGINX по ограничению скорости обработки запросов
Чаще всего путаются именно в логике отклонения запроса.
Здесь используются следующие концепции:
zone определяет «ведро» (bucket) — разделяемое пространство, в котором считаются входящие запросы. Все запросы, попавшие в одно «ведро», будут посчитаны и обработаны в его разрезе. Этим достигается возможность установки ограничений на основе URL, IP-адресов и т. д.
burst — необязательный параметр. Будучи установленным, он определяет количество запросов, которое может быть обработано сверх установленного базового ограничения скорости. Важно понимать, что burst — это абсолютная величина количества запросов, а не скорость.
Каким образом NGINX принимает решение о принятии или отклонении запроса?
При настройке зоны задается ее скорость. Например, при 300r/m будет принято 300 запросов в минуту, а при 5r/s — 5 запросов в секунду.
Важно понимать, что эти две зоны имеют одинаковые лимиты. С помощью параметра rate NGINX рассчитывает частоту и, соответственно, интервал, после которого можно принять новый запрос. В данном случае NGINX будет использовать алгоритм под названием «дырявое ведро» (leaky bucket).
Для NGINX 300r/m и 5r/s одинаковы: он будет пропускать один запрос каждые 0,2 с. В данном случае NGINX каждые 0,2 секунды будет устанавливать флаг, разрешающий прием запроса. Когда приходит подходящий для этой зоны запрос, NGINX снимает флаг и обрабатывает запрос. Если приходит очередной запрос, а таймер, считающий время между пакетами, еще не сработал, запрос будет отклонен с кодом состояния 503. Если время истекло, а флаг уже установлен в разрешающее прием значение, никаких действий выполнено не будет.
Нужны ли ограничение скорости обработки запросов и шейпинг трафика?
Когда приходит новый запрос, NGINX проверяет доступность токена (счетчик > 0). Если токен недоступен, запрос отклоняется. В противном случае запрос принимается и будет обработан, а токен считается израсходованным (счетчик уменьшается на один).
Хорошо, если есть неизрасходованные burst-токены, NGINX примет запрос. Но когда он его обработает?
Мы установили лимит в 5r/s, при этом NGINX примет запросы сверх нормы, если есть доступные burst-токены, но отложит их обработку таким образом, чтобы выдержать установленную скорость. То есть эти burst-запросы будут обработаны с некоторой задержкой или завершатся по таймауту.
Другими словами, NGINX не превысит установленный для зоны лимит, а поставит дополнительные запросы в очередь и обработает их с некоторой задержкой.
В случае использования NGINX в качестве прокси-сервера расположенные за ним сервисы будут получать запросы со скоростью 1r/s и ничего не узнают о всплесках трафика, сглаженных прокси-сервером.
Итак, мы только что настроили шейпинг трафика, применив задержки для управления всплесками запросов и выравнивания потока данных.
nodelay
Визуализация ограничений скорости обработки запросов
Здесь используется довольно простая конфигурация NGINX (она также есть в Docker-образе, ссылку на который можно найти в конце статьи):
Тестовая конфигурация NGINX с различными вариантами ограничения скорости обработки запросов
Во всех тестах, используя эту конфигурацию, мы отправляем одновременно по 10 параллельных запросов.
Давайте выясним вот что:
Делаем 10 параллельных запросов к ресурсу с ограничением скорости обработки запросов
10 одновременных запросов к ресурсу с ограничением скорости обработки запросов
В нашей конфигурации разрешено 30 запросов в минуту. Но в данном случае 9 из 10 будут отклонены. Если вы внимательно читали предыдущие разделы, такое поведение NGINX не станет для вас неожиданностью: 30r/m значит, что проходить будет только один запрос в 2 секунды. В нашем примере 10 запросов приходят одновременно, один пропускается, а остальные девять отклоняются, поскольку NGINX они видны до того, как сработает таймер, разрешающий следующий запрос.
Я переживу небольшие всплески запросов к клиентам/конечным точкам
10 одновременных запросов к ресурсу с аргументом burst=5
Ответ на первый запрос возвращается через 0,2 секунды. Таймер срабатывает через 2 секунды, один из ожидающих запросов обрабатывается, и клиенту приходит ответ. Общее время, затраченное на дорогу туда и обратно, составило 2,02 секунды. Спустя еще 2 секунды снова срабатывает таймер, давая возможность обработать очередной запрос, который возвращается с общим временем в пути, равным 4,02 секунды. И так далее и тому подобное…
Таким образом, аргумент burst позволяет превратить систему ограничения скорости обработки запросов NGINX из простого порогового фильтра в шейпер трафика.
Мой сервер выдержит дополнительную нагрузку, но я бы хотел использовать ограничение скорости обработки запросов для предотвращения его перегрузки
10 одновременных запросов к ресурсу с аргументом burst=5 nodelay
Подведем итоги
Чтобы не усложнять, отобразим количество входящих запросов (которые потом отклоняются либо принимаются и обрабатываются) на определяемой в настройках зоны временной шкале, разбитой на равные значению срабатывания таймера отрезки. Абсолютное значение временного интервала не существенно. Важно количество запросов, которое NGINX может обработать на каждом шаге.
Вот трафик, который мы будем прогонять через разные настройки ограничения скорости обработки запросов:
Входящие запросы и ограничение скорости обработки запросов, заданное для зоны
Принятые и отклоненные запросы (настройка burst не задана)
Без burst (то есть при burst=0 ) NGINX выполняет функцию ограничителя скорости. Запросы либо сразу обрабатываются, либо сразу отклоняются.
Принятые, принятые с задержкой и отклоненные запросы (с использованием burst)
Мы видим, что общее число отклоненных запросов уменьшилось. Были отклонены только те превышающие установленную скорость запросы, которые пришли в моменты, когда не было доступных burst-токенов. С такими настройками NGINX выполняет полноценный шейпинг трафика.
Наконец, NGINX можно использовать для управления трафиком путем ограничения размера пачки запросов (burst), но при этом всплески запросов частично будут доходить до их обработчиков (вышестоящих или локальных), что в конечном счете приведет к менее стабильной исходящей скорости, но улучшит сетевую задержку (если вы, конечно, можете обработать эти дополнительные запросы):
Принятые, обработанные и отклоненные запросы (burst используется с nodelay)
Поиграйте с ограничением скорости обработки запросов
Теперь, чтобы лучше закрепить понимание изложенных концепций, вы можете изучить код, скопировать репозиторий и поэкспериментировать с подготовленным Docker-образом: