microsoft - porta azure

El envío de alto rendimiento a EventHubs que resulta en MessagingException/TimeoutException/Server no pudo procesar los errores de solicitud

Question

Estamos experimentando muchas de estas excepciones al enviar eventos a EventHubs durante el tráfico pico:

"No se pudo enviar el evento a EventHub. Excepción: Microsoft.ServiceBus.Messaging.MessagingException: el servidor no pudo procesar la solicitud. Vuelva a intentar la operación. Si el problema persiste, póngase en contacto con su administrador de Service Bus y proporcione el ID de seguimiento". o "No se pudo enviar el evento a EventHub. Excepción: System.TimeoutException: la operación no finalizó dentro del tiempo asignado"

Puedes verlo claramente aquí:

Como puede ver, tenemos muchos Errores internos, Errores de servidor ocupados, Solicitud fallida cuando los mensajes entrantes superan los 400K eventos / hora (o ~ 270 MB / hora). Esto no es solo un problema transitorio. Está claramente relacionado con el rendimiento.

Nuestro EH tiene 32 particiones, retención de mensajes de 7 días y 5 unidades de rendimiento asignadas. OperationTimeout se establece en 5 minutos, y estamos usando la RetryPolicy predeterminada.

¿Es algo que aún tenemos que retocar aquí? Estamos realmente preocupados por la escalabilidad de EH.

Gracias

Answer 1

Después de una gran cantidad de excavaciones, decidimos dejar de configurar el PK para los mensajes publicados, y el problema simplemente desapareció. Estábamos usando GUID como PK. Comenzamos a obtener muy pocos errores en el Portal de Azure, y no más excepciones. Espero que esto ayude a alguien más

Answer 2

La sintonización del rendimiento de envío se puede lograr utilizando estrategias eficientes de distribución de particiones. No hay un solo botón que pueda hacer esto. A continuación se muestra la información básica que necesitará para diseñar Escenarios de alto riesgo.

1) Empecemos desde el espacio de nombres: las unidades de rendimiento (también conocidas como TU) se configuran en el nivel del espacio de nombres. Pls. tenga en cuenta que, se aplican las TU configuradas: agregado de todos los EventHubs bajo ese Namespace. Si tiene 5 TU en su Namespace y 5 Eventhubs, se dividirá entre los 5 Eventhubs.

2) Ahora veamos el nivel EventHub: si el EventHub está asignado con 5 TU y tiene 32 particiones: ninguna partición puede usar las 5 TU. Por ej. si está intentando enviar 5TU de datos a 1 partición y ''Zero'' a las otras 31 particiones, esto no es posible. El máximo que debe planificar por Partición es 1 TU. En general, deberá asegurarse de que los datos se distribuyan de manera uniforme en todas las particiones. EventHubs admite 3 tipos de envíos, lo que les da a los usuarios un nivel diferente de control en la distribución de particiones:

1. EventHubClient.Send (EventDataWithoutPartitionKey) -> si está utilizando esta API para enviar - eventhub se ocupará de distribuir los datos de manera uniforme en todas las particiones. La puerta de enlace del servicio EventHubs hará circular los datos en todas las particiones. Cuando una partición específica está inactiva, las Gateways detectan automáticamente y aseguran que los Clientes no vean ningún impacto. Esta es la forma más recomendada de Enviar a EventHubs .
2. EventHubClient.Send (EventDataWithPartitionKey) -> si está utilizando esta API para enviar a EventHubs, la partitionKey determinará la distribución de sus datos. PartitionKey se usa para almacenar Hash EventData en la partición adecuada (algo para hash es propiedad de Microsoft y no está compartido). Normalmente, los usuarios que requieren la correlación de un grupo de mensajes usarán esta variante de Enviar.
3. EventHubSender.Send (EventData) -> En esta variante, el emisor ya está adjunto a la partición. Entonces, esto otorga un control completo de la Distribución a través de las particiones al Cliente.

Para medir su distribución actual de datos, use EventHubClient.GetPartitionRuntimeInfo Api para estimar qué partición está sobrecargada. Se supone que la diferencia b / w BeginSequenceNumber y LastEnqueuedSequenceNumber da una estimación de la carga de las particiones en comparación con otras.

3) Por último, pero no menos importante: puede ajustar el rendimiento (no el rendimiento) en el nivel de operación de envío, utilizando SendBatch API. 1 TU puede comprar un máximo de 1000 ms / seg o 1MBPS - se le acelerará con el límite que llegue primero - esto no se puede cambiar. Si sus mensajes son pequeños, digamos 100 bytes y puede enviar solo 1000 mensajes por segundo (según el límite de TU), primero deberá alcanzar el límite de 1000 eventos / seg. Sin embargo, en general, utilizando la API SendBatch , puede procesar por lotes, por ejemplo, 10 de 100byte msgs y push a la misma velocidad, 1000 msgs / seg con solo 100 llamadas API y mejorar la latencia de extremo a extremo del sistema (ya que ayuda también al servicio para persistir mensajes de manera eficiente). Recuerde, la única limitación aquí es el Max. Tamaño de mensaje que se puede enviar, que es de 256 kb (este límite se aplicará en BatchSize si usa SendBatch API).

Teniendo en cuenta ese trasfondo, en su caso: - Tener 32 particiones y 5 TUs - Vería doblemente la estrategia de distribución de particiones.

HTH! Sree