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.
Uso de processEvent o processEventBatch
Al usar la devolución de processEvent llamada, cada EventData instancia recibió llamadas al 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 llamar continuamente a la devolución de llamada dificulta 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. El tiempo de procesamiento elevado en la devolución de llamada dificulta el EventProcessorClient rendimiento porque no sigue insertando más eventos de bajada ni solicita más EventData instancias 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 control, hay un costo de red a los puntos de control 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 control después de procesar cada EventData instancia dificultan el rendimiento debido al costo de realizar estas solicitudes HTTP. No debe realizar puntos de comprobación si la devolución de llamada no procesó ningún evento o debe controlarlo después de procesar algún número de eventos.
Usar LoadBalancingStrategy.BALANCED o LoadBalancingStrategy.GREEDY
Cuando se usa LoadBalancingStrategy.BALANCED, la EventProcessorClient notificación de 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 EventProcessorClient instancias, pueden usar LoadBalancingStrategy.GREEDY para reclamar su recurso compartido 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 predeterminado de captura previa es 500. Cuando se abre el vínculo de recepción de AMQP, coloca 500 créditos en el vínculo. Suponiendo que cada EventData instancia es un crédito de vínculo, EventProcessorClient captura previa 500 EventData instancias. 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 todavía EventProcessorClient tiene 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 amQP recibe créditos de vínculo, 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 mensajes x . Cuando se recibe cada EventData instancia, se coloca en una cola en memoria, en espera de procesarse. Un gran número de instancias de EventData 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 las bibliotecas cliente de Azure SDK para Java, se recomienda presentar un problema en el repositorio de GitHub del SDK de Azure para Java.