Mensajería JMS de alto rendimiento

Question

Leo diapositivas del UberConf de este año y uno de los oradores está argumentando que Spring JMS agrega una sobrecarga de rendimiento a su sistema de cola de mensajes; sin embargo, no veo ninguna evidencia que respalde eso en las diapositivas . El orador también defiende que el punto a punto es más rápido que el método tradicional de "publicar-suscribir" porque cada mensaje se envía solo una vez en lugar de transmitirse a cada consumidor.

Me pregunto si alguna gurús de mensajería Java experimentados pueden pesaje aquí y aclarar algunos aspectos técnicos:

• ¿Existe realmente una sobrecarga de rendimiento incurrido por el uso de primavera JMS en lugar de sólo JMS puros? Si es así, ¿cómo y dónde se introduce? ¿Hay alguna manera de evitarlo?
• ¿Qué evidencia real existe para apoyar que P2P es más rápido que el modelo pub-sub, y si es así, hay casos en los que desee pub-sub sobre P2P (es decir, por qué ir más lento?!?)?

Answer 1

1) primaria, la sobrecarga de la primavera JMS es el uso de JmsTemplate para enviar mensajes sin un mecanismo de caché debajo.Esencialmente, JmsTemplate hará lo siguiente para cada mensaje que envíe:

• Crear conexión
• Crear sesión
• Crear Productor
• Crear mensaje
• Enviar mensaje
• Cerrar Sesión
• Cerrar conexión

Este de podría ser comparado con el código escrito manualmente, donde se vuelve a utilizar cosas:

• Crear conexión
• Crear sesión
• Crear Productor
• Crear mensaje
• Enviar mensaje
• Crear mensaje
• Enviar mensaje
• Mensaje nuevo
• Enviar mensaje
• Cerrar Sesión
• Cerrar conexión

Desde la creación de conexiones, sesiones y productores necesita la comunicación entre el cliente y el proveedor de JMS y, por supuesto, la asignación de recursos, creará una sobrecarga bastante grande para muchos mensajes pequeños.

Puede solucionar esto almacenando en caché los recursos de JMS. Por ejemplo, utilice el resorte CachingConnectionFactory o ActiveMQs PooledConnectionFactory (si usa ActiveMQ, con el que ha etiquetado esta pregunta).

Si está ejecutando dentro de un contenedor completo de JavaEE, la agrupación/almacenamiento en caché suele estar incorporada e implícita cuando recupera su fábrica de conexiones JNDI.

Al receving, usando Spring Message Messageing Contenedor por defecto, hay una capa delgada en primavera que podría agregar poca sobrecarga, pero el aspecto principal es que puede ajustar el rendimiento en términos de concurrencia, etc. This article lo explica muy bien.

2)

PubSub es un patrón de uso, en el que el editor no necesita saber qué abonados que existe. No puedes simplemente emular eso con p2p. Y, sin ninguna prueba, defiendo que si desea enviar un mensaje idéntico de una aplicación a otras diez aplicaciones, una configuración de pub-sub sería más rápida que enviar el mensaje diez veces p2p.

Por otro lado, si solo tiene un productor y un consumidor, elija el patrón P2P con colas en su lugar, ya que es más fácil de administrar en algunos aspectos. P2P (colas) permite el equilibrio de carga, que pub/sub no (con la misma facilidad).

ActiveMQ también tiene una versión híbrida, VirtualDestinations - que esencialmente trata temas con equilibrio de carga.

La implementación real difiere según el proveedor, pero los temas y las colas no son fundamentalmente diferentes y deberían comportarse con un rendimiento similar. Lo que debe verificar es:

• ¿Persistencia? (= más lento)
• ¿Selectores de mensajes? (= más lento)
• ¿Concurrencia?
• ¿Suscriptores duraderos? (= Más lento)
• petición/respuesta, "sincrónica" con colas temporales (= sobrecarga = lento)
• Queue prefetching (rendimiento = impactos en algunos aspectos)
• almacenamiento en caché

Answer 2

No estoy Mensajería gurú, me gustaría que no me compartir mi pensamiento aquí;)

1. Siempre habrá por encima, porque tiene indirección adicional. Incluso es simplemente un nivel extra en la pila de llamadas, todavía está sobrecargado. Sin embargo, creo que dicha sobrecarga es mínima. Puede echar un vistazo al código fuente de JmsTemplate. No hay muchas cosas adicionales agregadas por Spring durante el envío. JmsTemplate está haciendo principalmente lo que necesita hacer si está utilizando JMS de todos modos. Siempre se puede argumentar que esas llamadas de verificación extra y de método más profundo siempre requieren más tiempo de CPU y memoria. Eso es cierto, pero me pregunto qué tan significativo es.

2. PubSub y P2P (Tema y cola en terminología JMS) son solo dos modelos diferentes. Creo que no pueden reemplazarse entre sí. No puede tener el comportamiento de "enviar una vez y transmitir a múltiples receptores" utilizando Cola, y al mismo tiempo no puede tener el comportamiento de entrega garantizada al usar Tema (a menos que use el Suscriptor Durable, pero ese es otro tema). Por lo tanto, elegir el tipo correcto depende de lo que está haciendo, en lugar de decir ciegamente que el P2P es superior a PubSub (que creo que es no-sentido)

Answer 3

1) plantillas Spring abrir/cerrar conexiones/sesiones para cada mensaje enviado/recibido. Es por eso que es más lento. La mayoría de las implementaciones JMS funcionan mejor cuando las conexiones/sesiones permanecen abiertas para que puedan usar optimizaciones como la precarga de mensajes sin mencionar la sobrecarga de hacer todos los ajustes de conexión/corte.

2) Los temas son generalmente más lentos si están copiando/replicando datos a más de un consumidor. Esto es solo una cuestión de física. Si se envían 10 megas de mensajes a la cola, entonces solo se deben transmitir 10 megas de datos a los consumidores. Mientras está en el tema, si tiene 10 consumidores y le envía 10 megas de datos, entonces 100 megas de datos deben transmitirse a los consumidores. Por lo tanto, para la mayoría de las implementaciones JMS:

• agregar un consumidor a un tema solo puede ralentizar su tasa de consumo.
• agregar un consumidor a una cola generalmente ayuda a aumentar la tasa de descarte.

Answer 4

¿Estás hablando de las diapositivas de Mark Richards? Publicó el código fuente de sus puntos de referencia, por lo que puede probar su afirmación sobre el rendimiento de JmsTemplate. Su código de referencia utiliza Spring CachingConnectionFactory, y sin embargo, a pesar del almacenamiento en caché todavía muestra una importante penalización de rendimiento con JmsTemplate. He ejecutado, perfilado y analizado su código. La respuesta corta es que la sobrecarga de JmsTemplate es insignificante y la disparidad de rendimiento medible en su código tiene que ver con los modos de envío asincrónico vs sincronización de ActiveMQ. He publicado mi análisis aquí:

JmsTemplate is not evil