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.

Usar processEvent ou processEventBatch

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

Se o hub de eventos tiver alto tráfego e uma alta taxa de transferência for esperada, o custo agregado de ligar continuamente para 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. O alto tempo de processamento no retorno de chamada prejudica o desempenho porque o EventProcessorClient não continua a enviar mais eventos para baixo nem a solicitar mais EventData instâncias do serviço Hubs de Eventos.

Custos dos pontos de controlo

Quando você usa o Armazenamento de Blobs do Azure como o armazenamento 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 da rede, ao desempenho do Armazenamento de Blobs do Azure, ao local do recurso e assim por diante.

O ponto de verificação depois que cada EventData instância é processada prejudica o desempenho devido ao custo de fazer essas solicitações HTTP. Você não deve verificar se seu retorno de chamada não processou nenhum evento, ou você deve verificar o ponto de verificação depois de processar algum número de eventos.

Use LoadBalancingStrategy.BALANCED ou LoadBalancingStrategy.GREEDY

Quando você usa LoadBalancingStrategy.BALANCEDo , declara EventProcessorClient 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 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 EventProcessorClient carga.

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

Configurar prefetchCount

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é-busca 500 EventData instâncias. Quando todos os eventos são consumidos, o cliente do processador 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.

A configuração prefetchCount pode ter implicações de desempenho se o número for muito baixo. Cada vez que o AMQP recebe o link 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 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 instâncias na fila pode resultar em um uso de EventData 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ê registre um problema no repositório do SDK do Azure para Java GitHub.