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 estiver à procura de soluções para outros problemas comuns que possa encontrar quando utiliza Hubs de Eventos, consulte Resolução de problemas de Hubs de Eventos do Azure.

Utilize processEvent ou processEventBatch

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

Se o hub de eventos tiver elevado tráfego e for esperada uma elevada taxa de transferência, o custo agregado de chamar continuamente o retorno de chamada prejudicará o desempenho do EventProcessorClient. Neste caso, use processEventBatch.

Para cada partição, seu retorno de chamada é invocado um de cada vez. Um elevado tempo de processamento na função de retorno de chamada prejudica o desempenho porque o EventProcessorClient não continua a enviar mais eventos a jusante nem a solicitar mais instâncias EventData ao serviço Event Hubs.

Custos dos pontos de controlo

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

A implementação de pontos de verificação após o processamento de cada instância EventData prejudica o desempenho devido ao custo de realizar essas solicitações HTTP. Não crie um ponto de verificação se o callback não tiver processado quaisquer eventos, ou crie um ponto de verificação após processar um determinado número de eventos.

Utilize LoadBalancingStrategy.BALANCED ou LoadBalancingStrategy.GREEDY

Ao usar LoadBalancingStrategy.BALANCED, o EventProcessorClient reivindica 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 poderão usar LoadBalancingStrategy.GREEDY para reivindicar sua parte 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 (número de pré-carregamento)

O valor de pré-busca padrão é 500. Quando o link de receção AMQP é aberto, atribui 500 créditos ao link. Supondo que cada EventData instância seja um crédito de link, EventProcessorClient pré-carrega 500 EventData instâncias. Quando o cliente processador consome todos os eventos, adiciona 500 créditos ao link para receber mais mensagens. Esse fluxo se repete enquanto o EventProcessorClient ainda tem a propriedade de uma partição.

Definir prefetchCount demasiado baixo pode afetar o desempenho. Cada vez que o link de receção do AMQP atribui créditos, o serviço remoto envia um ACK. Para cenários de alto rendimento, o sobrecusto de fazer milhares de pedidos de clientes e ACKs de serviço pode prejudicar o desempenho.

Definir prefetchCount demasiado alto pode afetar o desempenho. Quando x créditos são colocados na linha, 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 de memória muito alto.

Próximos passos

Se as orientações de resolução de problemas neste artigo não ajudarem a resolver os problemas ao utilizar as bibliotecas de cliente do SDK do Azure para Java, submeta um problema no repositório do GitHub do SDK do Azure para Java.