Solución de problemas de rendimiento de Azure Event Hubs

En este artículo se proporcionan soluciones a problemas comunes de rendimiento que pueden surgir al usar la biblioteca de Event Hubs en el SDK de Azure para Java. Si busca soluciones a otros problemas comunes que pueden surgir al usar Event Hubs, consulte Solución de problemas de Azure Event Hubs.

Utilice processEvent o processEventBatch

Al usar la devolución de llamada de processEvent, cada instancia de EventData recibe llamadas a su código. Este proceso funciona bien con tráfico bajo o moderado en el centro de eventos.

Si el centro de eventos tiene un alto tráfico y se espera un alto rendimiento, el costo agregado de invocar continuamente el callback afecta el rendimiento de EventProcessorClient. En este caso, use processEventBatch.

Para cada partición, la devolución de llamada se invoca de una en una. Un tiempo de procesamiento elevado en el callback dificulta el rendimiento porque EventProcessorClient no continúa subiendo más eventos aguas abajo ni solicita más instancias de EventData del servicio Event Hubs.

Costos de la creación de puntos de control

Cuando se usa Azure Blob Storage como almacén de puntos de comprobación, hay un costo de red asociado a la creación de puntos de comprobación porque realiza una solicitud HTTP y espera una respuesta. Este proceso puede tardar hasta varios segundos debido a la latencia de red, el rendimiento de Azure Blob Storage, la ubicación del recurso, etc.

Los puntos de comprobación después de procesar cada instancia de EventData dificultan el rendimiento debido al costo de realizar estas solicitudes HTTP. No cree puntos de comprobación si su función de devolución de llamada no ha procesado ningún evento, o después de procesar una cantidad determinada de eventos.

Uso de LoadBalancingStrategy.BALANCED o LoadBalancingStrategy.GREEDY

Cuando usas LoadBalancingStrategy.BALANCED, la EventProcessorClient reclama una partición para cada ciclo de equilibrio de carga. Si hay 32 particiones en un centro de eventos, se necesitan 32 iteraciones de equilibrio de carga para reclamar todas las particiones. Si los usuarios saben que se está ejecutando un número establecido de instancias de EventProcessorClient, pueden usar LoadBalancingStrategy.GREEDY para reclamar su parte de las particiones en un ciclo de equilibrio de carga.

Para más información sobre cada estrategia, consulte LoadBalancingStrategy.java en el repositorio azure-sdk-for-java.

Configuración de prefetchCount

El valor de captura previa predeterminado es de 500. Cuando se abre el enlace de recepción de AMQP, se asignan 500 créditos al enlace. Suponiendo que cada instancia de EventData es un crédito de vínculo, EventProcessorClient realiza una captura de 500 instancias de EventData. Cuando el cliente del procesador consume todos los eventos, agrega 500 créditos al vínculo para recibir más mensajes. Este flujo se repite mientras EventProcessorClient todavía tenga la propiedad de una partición.

El establecimiento de un valor prefetchCount demasiado bajo puede afectar al rendimiento. Cada vez que el enlace de recepción AMQP coloca créditos, el servicio remoto envía un ACK. En escenarios de alto rendimiento, la sobrecarga de realizar miles de solicitudes de cliente y ACK de servicio puede dificultar el rendimiento.

Configurar prefetchCount demasiado alto puede afectar al rendimiento. Cuando se colocan x créditos en la línea, el servicio Event Hubs sabe que puede enviar como máximo x mensajes. Cuando se recibe cada instancia de EventData, se coloca en una cola en memoria, en espera de procesarse. Tener un gran número de instancias de EventData en la cola puede dar lugar a un uso de memoria muy alto.

Pasos siguientes

Si la guía de solución de problemas de este artículo no ayuda a resolver problemas al usar la SDK de Azure para las bibliotecas cliente de Java, presente un problema en el SDK de Azure para Java GitHub repositorio.