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, debe usar 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 debería crear puntos de comprobación si su función de devolución de llamada no ha procesado ningún evento, o debería crearlos 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 vínculo de recepción de AMQP, coloca 500 créditos en el vínculo. Suponiendo que cada instancia de EventData es un crédito de vínculo, EventProcessorClient realiza una captura de 500 instancias de EventData. Cuando se consumen todos los eventos, el cliente del procesador 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.

prefetchCount La configuración puede tener implicaciones de rendimiento si el número es demasiado bajo. 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.

prefetchCount La configuración puede tener implicaciones de rendimiento si el número es demasiado alto. 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 resolución de problemas de este artículo no le ayuda a resolver los problemas al usar bibliotecas cliente de Azure SDK para Java, le recomendamos que deje la incidencia en el repositorio GitHub de Azure SDK para Java.