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, você deve usar 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. Você não deve fazer checkpoint se o seu retorno de chamada não processou nenhum evento, ou deve fazê-lo após processar algum 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 recebimento AMQP é aberto, ele coloca 500 créditos no link. Supondo que cada EventData instância seja um crédito de link, EventProcessorClient pré-carrega 500 EventData instâncias. Quando todos os eventos são processados, o cliente do sistema adiciona 500 créditos ao link para poder receber mais mensagens. Esse fluxo se repete enquanto o EventProcessorClient ainda tem a propriedade de uma partição.

A configuração prefetchCount pode ter implicações de desempenho se o número for muito baixo. Cada vez que o link de receção do AMQP atribui 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 clientes e ACKs de serviço pode prejudicar o desempenho.

A configuração prefetchCount pode ter implicações de desempenho se o número for muito alto. 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 diretrizes de solução de problemas neste artigo não ajudarem a resolver problemas quando você usa o SDK do Azure para bibliotecas de cliente Java, recomendamos que você arquive um problema no repositório SDK do Azure para Java GitHub.