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, use 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. Não crie um ponto de verificação se o seu retorno de chamada não processou nenhum evento, ou crie um ponto de verificação após processar um certo 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 o cliente do processador consome todos os eventos, ele adiciona 500 créditos ao link para receber mais mensagens. Esse fluxo se repete enquanto EventProcessorClient ainda tem a propriedade de uma partição.

A configuração prefetchCount muito baixa pode afetar o desempenho. 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 realizar milhares de solicitações de cliente e ACKs de serviço pode prejudicar o desempenho.

A configuração prefetchCount muito alta pode afetar o desempenho. 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 ao usar o SDK do Azure para bibliotecas de cliente Java, registre um problema no SDK do Azure para Java GitHub repositório.