Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Облачные собственные решения дают представление о неограниченных ресурсах, которые могут масштабироваться с рабочей нагрузкой. Хотя это понятие более верно в облаке, чем в локальных системах, существуют ограничения, которые существуют в облаке. Эти ограничения могут привести к ограничению запросов клиентских приложений как на стандартном, так и на премиальном уровнях, о которых говорится в этой статье.
Регулирование на стандартном уровне
Стандартный уровень служебная шина функционирует в мультитенантной среде с моделью оплаты по мере использования. Здесь несколько пространств имен в одном кластере используют выделенные ресурсы. Уровень "Стандартный" — это рекомендуемый вариант для сред разработчика, сред качества обслуживания и рабочих систем с низкой пропускной способностью.
В прошлом служебная шина имели строгие ограничения регулирования, зависящие от использования ресурсов. Однако есть возможность уточнить логику регулирования и обеспечить прогнозируемое поведение регулирования для всех пространств имен, совместно использующих эти ресурсы.
В попытке обеспечить справедливое использование и распределение ресурсов во всех стандартных пространствах имен служебная шина, использующих те же ресурсы, служебная шина стандарт в настоящее время использует логику регулирования на основе кредитов.
Note
Важно отметить, что троттлинг не является чем-то новым ни для Служебная шина Azure, ни для любого сервиса, изначально разработанного для облачной среды.
Ограничение пропускной способности на основе кредитов — это лишь усовершенствование механизма распределения ресурсов между различными пространствами имён в многопользовательской среде уровня Standard, что тем самым обеспечивает их справедливое использование всеми пространствами имён, совместно использующими эти ресурсы.
Что такое регулирование на основе кредитов?
Регулирование на основе кредитов ограничивает количество операций, которые могут выполняться в заданном пространстве имен в определенный период времени. Ниже приведен рабочий процесс регулирования на основе кредитов.
- В начале каждого периода служебная шина выделяет каждому пространству имён определённое количество кредитов.
- Все операции, выполняемые клиентскими приложениями отправителя или получателя, учитываются в отношении этих кредитов (и вычитаются из доступных кредитов).
- Если кредиты исчерпаны, скорость выполнения последующих операций будет ограничена до начала следующего периода.
- Кредиты пополняются в начале следующего периода.
Каковы кредитные ограничения?
В настоящее время кредитные лимиты равны 1000 кредитов каждую секунду (на пространство имен). Не все операции одинаковы. Ниже приведены кредитные затраты на каждую из операций.
| Операция | Стоимость кредита |
|---|---|
Операции с данными (Send, , SendAsyncReceive, ) ReceiveAsyncPeek |
1 кредит на сообщение |
Операции управления (Create, Read, Update, Delete для очередей, тем, подписок и фильтров) |
10 кредитов |
Note
При отправке в раздел каждое сообщение вычисляется по фильтрам, прежде чем быть доступным в подписке. Каждая оценка фильтра также учитывает кредитный лимит (то есть 1 кредит на оценку фильтра).
Как узнать, что моя скорость ограничивается?
Когда запросы клиентского приложения подвергаются ограничению, клиентское приложение получает от сервера следующий ответ.
The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.
Как избежать ограничения скорости?
При использовании общих ресурсов важно обеспечить справедливое использование между различными пространствами имён служебная шина, использующими эти ресурсы. Ограничение гарантирует, что любой всплеск в одной из рабочих нагрузок не приведёт к ограничению других рабочих нагрузок на одних и тех же ресурсах. Как далее упоминается в статье, риска столкнуться с ограничением запросов нет, поскольку в клиентские SDK и другие предложения Azure PaaS по умолчанию встроена политика повторных попыток. Все запросы, отклонённые из-за ограничения скорости, повторяются с экспоненциально увеличивающейся задержкой и в конечном итоге успешно выполняются после пополнения лимита.
Неудивительно, что некоторые приложения могут быть чувствительны к ограничению производительности. В этом случае мы рекомендуем вам перевести ваше текущее пространство имен служебная шина уровня Standard на уровень Premium. При миграции вы можете назначить выделенные ресурсы пространству имен служебная шина и при необходимости соответствующим образом увеличить их объем при всплеске рабочей нагрузки, чтобы снизить вероятность применения ограничений. Кроме того, когда рабочая нагрузка сокращается до обычных уровней, можно уменьшить объем ресурсов, выделенных для пространства имен.
Ограничение скорости на уровне "Премиум"
Уровень служебная шина Premium предоставляет выделенные ресурсы в виде единиц обмена сообщениями для каждого пространства имён, настроенного клиентом. Эти выделенные ресурсы обеспечивают прогнозируемую пропускную способность и задержку и рекомендуются для систем высокого уровня пропускной способности или конфиденциальной рабочей среды. Кроме того, уровень "Премиум" также позволяет клиентам масштабировать пропускную способность при возникновении пиков рабочей нагрузки. Дополнительные сведения см. в статье "Автоматическое обновление единиц обмена сообщениями" пространства имен служебной шины Azure.
Как работает ограничение пропускной способности в служебная шина Premium?
При выделении эксклюзивных ресурсов для уровня "Премиум" регулирование зависит исключительно от ограничений ресурсов, выделенных для пространства имен. Если число запросов превышает объём, который текущие ресурсы могут обслужить, то запросы ограничиваются.
Как узнать, что моя скорость ограничивается?
Существуют различные способы выявления ограничения пропускной способности на уровне "Премиум" в служебная шина.
- Запросы, обработка которых была ограничена отображаются в метриках запросов Azure Monitor, чтобы определить, сколько запросов было ограничено.
- Высокая загрузка ЦП указывает на то, что текущее потребление ресурсов велико, и запросы могут быть ограничены, если текущая нагрузка не снизится.
- Высокое использование памяти указывает на то, что текущее потребление ресурсов велико, и обработка запросов может быть ограничена, если текущая нагрузка не снизится.
Как избежать ограничения скорости?
Поскольку пространство имен служебная шина уровня "Премиум" уже имеет выделенные ресурсы, вы можете снизить вероятность ограничения пропускной способности, увеличив количество единиц обмена сообщениями, выделенных вашему пространству имен, в случае (или в ожидании) всплеска нагрузки. Дополнительные сведения см. в статье "Автоматическое обновление единиц обмена сообщениями" пространства имен служебной шины Azure.
Ограничение при превышении допустимого предела одновременных запросов на получение данных
Помимо регулирования по ресурсам и кредитам, описанного ранее, служебная шина также ограничивает количество одновременных запросов на получение для отдельной сущности. Очередь, тема или подписка допускает до 5 000 одновременных запросов на получение. Для темы это ограничение применяется к общему числу одновременных операций получения во всех ее подписках. Если число одновременно обрабатываемых запросов на получение для объекта превышает это ограничение, система отклоняет дополнительные запросы на получение с ошибкой "Сервер занят" до тех пор, пока количество невыполненных запросов не станет меньше этого ограничения.
Эта ситуация обычно возникает, когда приложение открывает большое количество приёмников (ссылок получения AMQP) для одной и той же сущности и оставляет их активными одновременно. Каждый открытый получатель выделяет службе кредит и постоянно опрашивает наличие сообщений, даже если в сущности нет сообщений. При достаточно большом количестве одновременно работающих получателей совокупное число запросов на получение превышает лимит, и сущность начинает возвращать ошибки "сервер занят".
Пакеты SDK служебная шина обрабатывают ответ занятого сервера с помощью встроенной политики повторных попыток, которая использует экспоненциальную обратную передачу, чтобы повторные попытки не добавляли дополнительную нагрузку. Чтобы избежать достижения этого ограничения в первую очередь, следуйте приведенным ниже рекомендациям.
- Поддерживайте число одновременных приемников для одного объекта значительно ниже ограничения. Для достижения высокой пропускной способности обычно достаточно нескольких получателей на экземпляр потребителя. Открытие тысяч получателей для одной сущности — это антипаттерн, который повышает вероятность троттлинга, не улучшая пропускную способность.
- Закрывайте приемники, которые вам больше не нужны, вместо того чтобы держать неиспользуемые приемники открытыми и выполнять их опрос.
- Горизонтальное масштабирование между несколькими сущностями, например путем секционирования рабочей нагрузки по нескольким очередям или подпискам, если вам действительно требуется очень большое количество одновременных потребителей.
FAQs
Как ограничение скорости влияет на моё приложение?
Когда запрос подвергается ограничению, это означает, что служба занята, поскольку получает больше запросов, чем позволяют доступные ресурсы. Если одна и та же операция повторяется через несколько минут, после того как служба проработала текущую рабочую нагрузку, то запрос может быть выполнен.
Поскольку ограничение пропускной способности является ожидаемым поведением любого облачного сервиса, изначально спроектированного для облачной среды, логика повторных попыток встроена в сам SDK служебная шина. По умолчанию используются автоматические повторные попытки с экспоненциально увеличивающейся задержкой, чтобы один и тот же запрос не попадал под ограничение частоты при каждом повторе. Логика повторных попыток по умолчанию применяется к каждой операции.
Note
Код обработки сообщений, вызывающий другие сторонние службы, также может регулироваться другими службами. Дополнительные сведения о том, как работать с этими сценариями, см. в документации по шаблону ограничения скорости.
Приводит ли ограничение скорости к потере данных?
Служебная шина Azure оптимизирован для сохраняемости. Мы гарантируем, что все данные, отправленные в служебная шина, сохраняются в хранилище до того, как служба подтвердит успешное выполнение запроса.
После успешного подтверждения запроса служебная шина предполагается, что служебная шина успешно обработал запрос. Если служебная шина возвращает сбой, это означает, что служебная шина не удалось обработать запрос, и клиентское приложение должно повторить запрос.
Однако, если запрос ограничивается из-за превышения лимита, это означает, что служба в данный момент не может принять и обработать его из-за ограниченности ресурсов. Это не означает никакой потери данных, так как служебная шина просто не посмотрел на запрос. В этом случае использование стандартной политики повторных попыток в SDK служебная шина гарантирует, что запрос будет в конечном итоге обработан.
Связанный контент
Дополнительные сведения и примеры использования обмена сообщениями в служебной шине см. в следующих расширенных темах: