Otimizar seu bot com limitação de fluxo no Teams
A limitação de taxa é um método para limitar as mensagens a uma determinada frequência máxima. Como princípio geral, seu aplicativo deve limitar o número de mensagens postadas em um chat individual ou conversa de canal. Isto garante uma experiência ideal e as mensagens não aparecem como spam para os seus utilizadores.
Para proteger o Microsoft Teams e seus usuários, as APIs do bot fornecem um limite de taxa para solicitações de entrada. Os aplicativos que superam esse limite recebem um status de erro HTTP 429 Too Many Requests. Todas as solicitações estão sujeitas à mesma política de limitação de taxa, incluindo envio de mensagens, enumerações de canal e buscas de lista de participantes.
Como os valores exatos dos limites de taxa estão sujeitos a alterações, seu aplicativo deve implementar o comportamento de retirada apropriado quando a API retornar HTTP 429 Too Many Requests.
Lidar com limites de taxa
Ao emitir uma operação SDK do Bot Builder, você pode lidar com Microsoft.Rest.HttpOperationException e verificar o código de status.
O código a seguir mostra um exemplo de como lidar com limites de taxa:
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
}
}
Depois de lidar com os limites de taxa para bots, você pode lidar com respostas HTTP 429 usando uma retirada exponencial.
Lidar com as respostas HTTP 429
Tem de tomar precauções simples para evitar receber HTTP 429 respostas. Por exemplo, evite emitir várias solicitações para a mesma conversa pessoal ou de canal. Em vez disso, crie um lote de solicitações de API.
Usar uma retirada exponencial com um jitter aleatório é a maneira recomendada de lidar com 429s. Isto garante que vários pedidos não introduzem colisões nas repetições.
Depois de lidar com as respostas HTTP 429, você pode percorrer o exemplo para detectar exceções transitórias.
Observação
Além de tentar novamente o código de erro 429, os códigos de erro 412, 502 e 504 também devem ser repetidos.
Exemplo de detecção de exceções transitórias
O código a seguir mostra um exemplo de uso de retirada exponencial usando o bloco de aplicativos de tratamento de falhas transitórias:
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);
}
}
Você pode executar retirada e novas tentativas usando o tratamento de falhas transitórias. Para obter diretrizes sobre como obter e instalar o pacote NuGet, consulte adicionar o bloco de aplicativos de tratamento de falhas transitórias à sua solução. Consulte também tratamento de falhas transitórias.
Depois de percorrer o exemplo para detectar exceções transitórias, consulte o exemplo de retirada exponencial. Você pode usar retirada exponencial em vez de tentar novamente em caso de falhas.
Exemplo de retirada
Além de detectar limites de taxa, você também pode executar uma retirada exponencial.
O código a seguir mostra um exemplo de retirada exponencial:
/**
* 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 ExponentialBackoffRetryStrategy(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);
Você também pode executar um método System.Action com a política de repetição descrita nesta seção. A biblioteca referenciada também permite que você especifique um intervalo fixo ou um mecanismo de retirada linear.
Armazene o valor e a estratégia em um arquivo de configuração para refinar e ajustar valores em tempo de execução.
Para obter mais informações, consulte padrões de repetição.
Você também pode lidar com o limite de taxa usando o limite de threads por bot.
Limite de threads por bot
O limite de threads por bot controla o tráfego que um bot tem permissão para gerar em uma única conversa. Uma conversa é 1:1 entre o bot e o usuário, um chat em grupo ou um canal em uma equipe. Por isso, se a aplicação enviar uma mensagem de bot a cada utilizador, o limite de threads não será limitado.
Observação
- O limite de threads de 3.600 segundos e 1800 operações se aplicará somente se várias mensagens de bot forem enviadas para um único usuário.
- O limite global por aplicativo por locatário é de 50 RPS (Solicitações por Segundo). Portanto, o número total de mensagens de bot por segundo não deve ultrapassar o limite de threads.
- A divisão de mensagens no nível de serviço resulta em RPS maior do que o esperado. Se você estiver preocupado com a aproximação dos limites, deverá implementar a estratégia de retirada. Os valores fornecidos nesta seção são apenas para estimativa.
A tabela a seguir fornece os limites de thread por bot:
| Cenário | Tempo em segundos | Máximo de operações permitidas |
|---|---|---|
| Enviar para conversa | 1 | 7 |
| Enviar para conversa | 2 | 8 |
| Enviar para conversa | 30 | 60 |
| Enviar para conversa | 3600 | 1800 |
| Criar conversa | 1 | 7 |
| Criar conversa | 2 | 8 |
| Criar conversa | 30 | 60 |
| Criar conversa | 3600 | 1800 |
| Obter membros da conversa | 1 | 14 |
| Obter membros da conversa | 2 | 16 |
| Obter membros da conversa | 30 | 120 |
| Obter membros da conversa | 3600 | 3600 |
| Conversas de bot | 1 | 14 |
| Conversas de bot | 2 | 16 |
| Conversas de bot | 30 | 120 |
| Conversas de bot | 3600 | 3600 |
Observação
Versões anteriores de APIs TeamsInfo.getMembers e TeamsInfo.GetMembersAsync estão sendo preteridas. São limitados a cinco solicitações por minuto e retornam um máximo de 10 mil membros por equipe. Para atualizar o SDK do Bot Framework e o código para usar os pontos de extremidade de API paginados mais recentes, consulte Alterações de API do Bot para membros de equipe e chat.
Você também pode lidar com o limite de taxa usando o limite de threads para todos os bots.
Limite de threads para todos os bots
O limite de threads para todos os bots controla o tráfego que todos os bots têm permissão para gerar em uma única conversa. Uma conversa aqui é 1:1 entre bot e utilizador, uma conversa de grupo ou um canal numa equipa.
A tabela a seguir fornece o limite de thread para todos os bots:
| Cenário | Tempo em segundos | Máximo de operações permitidas |
|---|---|---|
| Enviar para conversa | 1 | 14 |
| Enviar para conversa | 2 | 16 |
| Criar conversa | 1 | 14 |
| Criar conversa | 2 | 16 |
| Criar conversa | 1 | 14 |
| Criar conversa | 2 | 16 |
| Obter membros da conversa | 1 | 28 |
| Obter membros da conversa | 2 | 32 |
| Conversas de bot | 1 | 28 |
| Conversas de bot | 2 | 32 |