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

  • Статья

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

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

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

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

При публикации операции 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.

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

После обработки ответов (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 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 см. в статье Добавление в решение блока приложения обработки временных сбоев. Также см. статью Обработка временных сбоев.

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

Пример отхода

Помимо определения пределов скорости, вы также можете выполнить экспоненциальный отход.

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

/**
* 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 с помощью политики повторных попыток, описанной в этом разделе. Указанная библиотека также позволяет указать фиксированный интервал или линейный механизм отхода.

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

Дополнительные сведения см. в статье Шаблоны повторных попыток.

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

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

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

Примечание.

  • Ограничение потока в 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

Примечание.

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

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

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

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

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

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

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

Боты для звонков и виртуальных собраний

См. также