Azure Service Bus - Desafío de rendimiento de comunicación bidireccional

Question

Necesito establecer una comunicación bidireccional entre un publicador y un suscriptor. Esto es para facilitar una aplicación front-end MVC3 que define una suscripción con un filtro de correlación, y luego colocar un mensaje en un tema. Finalmente, el controlador MVC3 llama a BeginReceive() en el Cliente de suscripción, y espera la respuesta.

El problema parece ser la creación y eliminación de estos objetos de Suscripción. La sobrecarga es enorme y ralentiza la aplicación a paso de tortuga. Esto sin mencionar las diversas limitaciones para evitar, como no más de 2000 Suscripciones en un tema.

¿Cuál es la mejor práctica para establecer este tipo de comunicación bidireccional entre un publicador y un suscriptor? Queremos que la aplicación MVC3 publique un mensaje y luego espere una respuesta a ese mensaje exacto (a través de la propiedad CorrelationId y un CorrelationFilter). Ya almacenamos en caché NamespaceManager y MessagingFactory, ya que también son prohibitivamente caros, en cuanto a los recursos, y también porque se nos avisó que Service Bus utiliza un modelo de aprovisionamiento explícito, donde se espera precrear la mayoría de estas cosas durante el inicio del rol.

Por lo tanto, esto nos deja con el desafío de correlacionar la solicitud a la respuesta, y tener esta gran sobrecarga de la creación y eliminación de Suscripciones. ¿Qué mejor práctica existe? ¿Deberíamos mantener un caché de SubscriptionClients e intercambiar el filtro cada vez? ¿Qué hacen todos los demás? Necesito tener un rendimiento de solicitudes del orden de 5 a 10 mil solicitudes de MVC3 por segundo a través del clúster de roles web. Ya estamos usando AsyncController y empleando el BeginReceive asincrónico() en SubscriptionClient. Parece ser la creación y eliminación de las Suscripciones por miles lo que está estrangulando el sistema en este punto.

Update1: Basado en el gran consejo aquí proporcionada, hemos actualizado esta solución para mantener una caché de objetos SubscriptionClient en cada instancia de rol web. Además, hemos migrado a un enfoque orientado a MessageSession.

Sin embargo, esto todavía no está escalando. Parece que AcceptMessageSession() es una operación muy costosa. ¿Deberían los objetos MessageSession también almacenarse en caché y reutilizarse? ¿Cada objeto abierto MessageSession consume una conexión al Bus de servicio? Si es así, ¿esto se cuenta en contra de la cuota de conexión simultánea de la Suscripción?

Muchas gracias. Creo que estamos llegando. La mayor parte del código de ejemplo en la web muestra: Create Topic(), luego CreateSubscription(), luego CreateSubscriptionClient(), luego BeginReceive() en el cliente, luego el desmontaje de todos los objetos. Todo lo que puedo decir es que si hicieras esto en la vida real, tu servidor quedaría aplastado y maximizarías las conexiones en poco tiempo.

Tenemos que poner miles de solicitudes por segundo a través de esta cosa, y es muy evidente que estos objetos deben almacenarse en caché y reutilizarse en gran medida. Entonces, ¿MessageSession es otro elemento para caché? Me divertiré almacenando en caché eso, porque tendremos que implementar un mecanismo de recuento de referencias, donde solo se puede dar una referencia a MessageSession a la vez, ya que esto es para solicitud/respuesta específica de solicitud http, y no podemos tener otra suscriptores que usan los objetos MessageSession al mismo tiempo.

Update2: OK, no es factible MessageSession caché para su reutilización, ya que sólo viven tanto como el LockDuration en la suscripción. Esto es un fastidio, porque el LockDuration máximo es de 5 minutos. Estos parecen ser para pub/sub de corta duración, no para procesos distribuidos de larga ejecución. Parece que tenemos que volver a sondear Azure Tables.

RESUMEN/COMENTARIO Nos trató de construir el servicio de autobuses debido a la escala potencial y su semántica de durabilidad y entrega. Sin embargo, parece que hay situaciones, solicitudes/respuestas de alto volumen entre ellas, que no son adecuadas. La parte de publicación funciona muy bien, y tener consumidores que compiten en el back-end es excelente, pero tener una solicitud de front-end esperar en una respuesta definida de consumidor único, no se escala bien, porque las MessageSessions toman demasiado tiempo para crear a través de AcceptMessageSession() o BeginAcceptMessageSession(), y porque no son adecuados para el almacenamiento en caché.

Si alguien tiene una vista alternativa, me encantaría escucharla.

Answer 1

Este escenario es una solicitud/respuesta clásica y un buen candidato para usar sesiones. Estos son otro mecanismo de correlación. Haga una cola de solicitud simple y una cola de respuesta. Cada subproceso de rol web crea un sessionid único para una solicitud y pone ese valor en la propiedad "ReplyToSessionID" del mensaje brokeredmessage. Además, este hilo llama a AcceptMessageSession en la cola de respuesta con el valor de sesión para que lo bloquee. El mensaje intermediario se envía a la cola de solicitudes y todas las funciones de los trabajadores compiten por los mensajes. Cuando una función de trabajador obtiene una solicitud, la procesa, crea un mensaje de respuesta y establece la propiedad de sesión en el mensaje de respuesta = respuesta de la solicitud. esto luego se envía a la cola de respuesta y solo se entregará al hilo que ha bloqueado esa identificación de la sesión. Una muestra detallada using sessions is here. Hay 2 muestras adicionales aquí usando Queues y Topics para lograr la correlación de respuesta de solicitud.

Answer 2

Para un solo emisor y receptor solo necesita tener un solo tema/suscripción. Puede configurar varios correlation filters en la misma suscripción y así tener todas las respuestas que necesita correlacionadas aparecer en la misma suscripción. Actualmente admitimos hasta 100,000 instancias de filtro de correlación en una sola suscripción y estas se pueden agregar/eliminar (con transacciones si es necesario) junto con las operaciones de envío/recepción de mensajes sobre el tema/suscripción.

Además, puede usar Reglas con acciones para sellar el mensaje con propiedades adicionales si es necesario según el filtro que coincida.

Answer 3

Un enfoque alternativo es realizar una correlación de mensajes en la instancia de rol web utilizando un diccionario de id. De correlación y delegados de devolución de llamada.

Cada instancia de rol web (editor) tiene una sola suscripción, filtrada por una única ID de suscripción, al tema de respuesta.

Antes de enviar un mensaje, la devolución de llamada para ese mensaje se registra en el diccionario con la identificación de correlación como la clave. La ID de correlación y una ID de suscripción se envían junto con el mensaje de modo que la respuesta se pueda enviar de vuelta a la suscripción correcta junto con la ID de correlación.

Cada instancia de rol web supervisa la suscripción única y al recibir la respuesta elimina la entrada del diccionario e invoca la devolución de llamada.