Оптимизация бота с ограничением скорости в Teams

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

Для защиты Microsoft Teams пользователей API-бота предоставляют ограничение скорости для входящих запросов. Приложения, которые преодолеют это ограничение, получают HTTP 429 Too Many Requests состояние ошибки. Все запросы подчиняются одной и той же политике ограничения скорости, включая отправку сообщений, список каналов и извлечение реестра.

Поскольку точные значения ограничений скорости могут изменяться, ваше приложение должно реализовать соответствующее поведение при возврате HTTP 429 Too Many Requests API.

Ограничения скорости обработки

При выдаче SDK-операции Bot Builder можно обрабатывать и Microsoft.Rest.HttpOperationException проверять код состояния.

В следующем коде показан пример ограничения скорости обработки:

try
{
    // Perform Bot Framework operation
    // for example, await connector.Conversations.UpdateActivityAsync(reply);
}
catch (HttpOperationException ex)
{
    if (ex.Response != null && (uint)ex.Response.StatusCode ==  429)
    {
        //Perform retry of the above operation/Action method
    }
}

После обработки ограничений скорости для ботов можно обрабатывать ответы с HTTP 429 помощью экспоненциального отработки.

Обработка HTTP 429 ответов

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

Использование экспоненциального отработки со случайным испугом — это рекомендуемый способ обработки 429s. Это гарантирует, что в нескольких запросах не будут вводиться столкновения при повторном запросе.

После обработки ответов можно перейти к примеру для обнаружения HTTP 429 временных исключений.

Примечание

В дополнение к повторной ошибке код 429, коды ошибок 412, 502 и 504 также должны быть повторно.

Обнаружение примера временных исключений

В следующем коде показан пример использования экспоненциального отработки с помощью преходящего блока обработки ошибок приложения:

public class BotSdkTransientExceptionDetectionStrategy : ITransientErrorDetectionStrategy
    {
        // List of error codes to retry on
        List<int> transientErrorStatusCodes = new List<int>() { 429 };

        public static bool IsTransient(Exception ex)
          {
              if (ex.Message.Contains("429"))
                  return true;

              HttpResponseMessageWrapper? response = null;
              if (ex is HttpOperationException httpOperationException)
              {
                  response = httpOperationException.Response;
              }
              else
              if (ex is ErrorResponseException errorResponseException)
              {
                  response = errorResponseException.Response;
              }
              return response != null && transientErrorStatusCodes.Contains((int)response.StatusCode);
          }
    }

Вы можете выполнять отработку и повторное выполнение с помощью обработки временных ошибок. Рекомендации по получению и установке пакета NuGet см. в добавлении к решению блока обработки сбоя. См. также переходную обработку с ошибками.

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

Пример backoff

Помимо обнаружения ограничений скорости, вы также можете выполнить экспоненциальный отсев.

В следующем коде показан пример экспоненциального отсевов:

/**
* The first parameter specifies the number of retries before failing the operation.
* The second parameter specifies the minimum and maximum backoff time respectively.
* The last parameter is used to add a randomized  +/- 20% delta to avoid numerous clients retrying simultaneously.
*/
var exponentialBackoffRetryStrategy = new ExponentialBackoff(3, TimeSpan.FromSeconds(2),
                        TimeSpan.FromSeconds(20), TimeSpan.FromSeconds(1));


// Define the Retry Policy
var retryPolicy = new RetryPolicy(new BotSdkTransientExceptionDetectionStrategy(), exponentialBackoffRetryStrategy);

//Execute any bot sdk action
await retryPolicy.ExecuteAsync(() => connector.Conversations.ReplyToActivityAsync( (Activity)reply) ).ConfigureAwait(false);

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

Храните значение и стратегию в файле конфигурации для настройки и настройки значений во время запуска.

Дополнительные сведения см. в шаблонах повторного получения.

Вы также можете обрабатывать ограничение скорости с помощью каждого бота в потоке.

Ограничение на один бот на поток

Ограничение для каждого бота в потоке управляет трафиком, который может создаваться ботом в одном разговоре. Беседа 1:1 между ботом и пользователем, групповым чатом или каналом в команде. Таким образом, если приложение отправляет по одному сообщению бота каждому пользователю, ограничение потока не затормажается.

Примечание

  • Ограничение потока в 3600 секунд и 1800 операций применяется только в том случае, если несколько сообщений бота отправляются одному пользователю.
  • Глобальное ограничение для каждого клиента — 50 запросов в секунду (RPS). Таким образом, общее число сообщений бота в секунду не должно пересекать ограничение потока.
  • Разделение сообщений на уровне службы приводит к большему, чем ожидалось, RPS. Если вас беспокоит приближение к ограничениям, необходимо реализовать стратегию обратного выхода. Значения, предоставляемые в этом разделе, являются только для оценки.

В следующей таблице содержится ограничение для каждого бота на поток:

Сценарий Период времени в секундах Максимально допустимые операции
Отправка в беседу 1 7
Отправка в беседу 2 8
Отправка в беседу 30 60
Отправка в беседу 3600 1800
Создание беседы 1 7
Создание беседы 2 8
Создание беседы 30 60
Создание беседы 3600 1800
Получить участников беседы 1 14
Получить участников беседы 2 16
Получить участников беседы 30 120
Получить участников беседы 3600 3600
Получать беседы 1 14
Получать беседы 2 16
Получать беседы 30 120
Получать беседы 3600 3600

Примечание

Предыдущие версии и TeamsInfo.getMembers TeamsInfo.GetMembersAsync API отстают. Они отлаговываются до пяти запросов в минуту и возвращают не более 10 000 участников на каждую команду. Чтобы обновить SDK bot Framework и код для использования последних конечных точек API с paginated, см. в рубрике Изменения API bot для членов команды и чата.

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

Ограничение потока для всех ботов

Ограничение потока для всех ботов контролирует трафик, который всем ботам разрешено создавать в одном диалоге. Беседа здесь 1:1 между ботом и пользователем, групповой чат или канал в команде.

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

Сценарий Период времени в секундах Максимально допустимые операции
Отправка в беседу 1 14
Отправка в беседу 2 16
Создание беседы 1 14
Создание беседы 2 16
Создание беседы 1 14
Создание беседы 2 16
Получить участников беседы 1 28
Получить участников беседы 2 32
Получать беседы 1 28
Получать беседы 2 32

Следующий этап