Solucionar problemas de desempenho dos Hubs de Eventos do Azure

Este artigo fornece soluções para problemas comuns de desempenho que você pode encontrar ao usar a biblioteca de Hubs de Eventos no SDK do Azure para Java. Se você estiver procurando soluções para outros problemas comuns que você pode encontrar ao usar Os Hubs de Eventos, confira solução de problemas dos Hubs de Eventos do Azure.

Usar processEvent ou processEventBatch

Quando você usa o processEvent callback, cada instância EventData recebida executa seu código. Esse processo funciona bem com tráfego baixo ou moderado no hub de eventos.

Se o hub de eventos tiver tráfego alto e uma alta taxa de transferência for esperada, o custo agregado de sempre chamar o retorno de chamada prejudicará o desempenho de EventProcessorClient. Nesse caso, você deve usar processEventBatch.

Para cada partição, o retorno de chamada é invocado um por vez. O alto tempo de processamento no retorno de chamada prejudica o desempenho porque EventProcessorClient não continua enviando mais eventos downstream nem solicita mais instâncias de EventData do serviço Hubs de Eventos.

Custos do ponto de verificação

Quando você usa o Armazenamento de Blobs do Azure como o repositório de ponto de verificação, há um custo de rede para o ponto de verificação porque ele faz uma solicitação HTTP e aguarda uma resposta. Esse processo pode levar até vários segundos devido à latência de rede, ao desempenho do Armazenamento de Blobs do Azure, ao local do recurso e assim por diante.

A criação de ponto de verificação cada vez que uma instância de EventData é processada prejudica o desempenho devido ao custo associado a essas solicitações HTTP. Você não deverá criar o ponto de verificação se o retorno de chamada não processou nenhum evento, ou deverá criar o ponto de verificação depois de processar um determinado número de eventos.

Usar LoadBalancingStrategy.BALANCED ou LoadBalancingStrategy.GREEDY

Quando você usa LoadBalancingStrategy.BALANCED, EventProcessorClient assegura uma partição para cada ciclo de balanceamento de carga. Se houver 32 partições em um hub de eventos, serão necessárias 32 iterações de balanceamento de carga para reivindicar todas as partições. Se os usuários souberem que um número definido de EventProcessorClient instâncias está em execução, eles podem usar LoadBalancingStrategy.GREEDY para reivindicar seu compartilhamento das partições em um ciclo de balanceamento de carga.

Para obter mais informações sobre cada estratégia, consulte LoadBalancingStrategy.java no repositório azure-sdk-for-java.

Configurar prefetchCount

O valor pré-busca padrão é 500. Quando o link de recebimento do AMQP é aberto, ele coloca 500 créditos no link. Supondo que cada instância EventData seja um crédito de link, EventProcessorClient irá pré-carregar 500 instâncias EventData. Quando todos os eventos são consumidos, o cliente do processador adiciona 500 créditos à conexão para receber novas mensagens. Esse fluxo se repete enquanto EventProcessorClient ainda tem a propriedade de uma partição.

A configuração prefetchCount poderá ter implicações de desempenho se o número for muito baixo. Cada vez que o link de recebimento AMQP coloca créditos, o serviço remoto envia um ACK. Para cenários de alta taxa de transferência, a sobrecarga de fazer milhares de solicitações de cliente e ACKs de serviço pode prejudicar o desempenho.

A configuração prefetchCount poderá ter implicações de desempenho se o número for muito alto. Quando x créditos são ativados, o serviço Hubs de Eventos sabe que pode enviar no máximo x mensagens. Quando cada EventData instância é recebida, ela é colocada em uma fila na memória, aguardando para ser processada. Um alto número de EventData instâncias na fila pode resultar em um uso muito alto de memória.

Próximas etapas

Se as diretrizes de solução de problemas neste artigo não ajudarem a resolver problemas quando você usa o SDK do Azure para bibliotecas de clientes Java, recomendamos que você registre um problema no repositório GitHub do Azure SDK para Java.