Comparativa de servidores JMS OpenSource

Matt Brassier ha publicado una comparativa de desempeño de servidores JMS open source. Los servidores probados son JBoss Messaging, JBoss MQ y Sun Java System Message Queue (OpenMQ) que es el que viene en Glassfish v2.

Las pruebas de benchmark se hicieron con la configuración por defecto de los servidores, aunque se planea realizar pruebas en el futuro con configuraciones personalizadas.

Se usaron 2 servidores Amazon EC2: 1 para montar el servidor JMS y el otro para ejecutar el cliente de prueba. El cliente utiliza varios threads para encolar mensajes en un Queue JMS. El cliente fue configurado para generar 5 threads y enviar mensajes con Strings de alrededor de 30 caracteres.

Se probaron dos casos: abrir una conexión al servidor y enviar todos mensajes y abrir una conexión, enviar un mensaje y cerrarla, de forma repetida.

Para el primer caso JBoss Messaging fue el servidor con mejores tiempos. Para el segundo, lo fue JBoss MQ. Por su parte, OpenMQ tuvo un desempeño muy malo enviando pequeños lotes de mensajes pero en el caso de enviar largos lotes de mensajes, su desempeño fue similar al de JBossMQ.

La siguiente tabla muestra el tiempo en ms que se tardó cada servidor en colocar el número de mensajes especificado en cada columna en su Queue:

Implementation\ Batch Size	1	10	100	1000	10000
JBoss Messaging	99	106	485	1367	15595
JBoss MQ	55	48	423	2224	21183
GlassFish OpenMQ	267	304	972	2760	21183

La siguiente tabla muestra el tiempo en ms que toma  enviar 1 solo mensaje a la Queue conforme el número de mensajes va creciendo:

Messages	JBoss Messaging	JBoss MQ	GlassFish OpenMQ
1	99	56	268
10	10.6	4.8	30.4
100	4.8	4.2	9.7
1000	1.36	2.2	2.7
10000	1.36	2

Por otro lado, el número de mensajes se iba incrementando por 10 cada vez y más alla de los 10000 los servidores empezaron a lanzar fallos. Matt ha resumido los fallos reportados por el servidor y con que número de mensajes sucedieron:

Implementation	Failure point	Nature of failure
JBoss MQ	1000000	Server ran out of memory and stopped responding.
JBoss Messaging	100000	Server threw OutOfMemory errors, client stopped responding.
Glassfish OpenMQ	100000	Client receives errors indicating that the server is no longer accepting messages. The server continues to respond to other requests.

 En las conclusiones, el autor hace notar que JBoss MQ tuvo un mejor desempeño en casos en que se  abría y cerraba una conexión JMS con cada mensaje enviado, mientras que JBoss Messaging la tuvo en los casos en que una misma conexión se usa para enviar un  número grande de mensajes. Como hace notar Matt, lo más recomendable al usar JMS es el segundo caso, usar una misma conexión mientras el cliente envíe mensajes.

En cuanto a los fallos, Matt pone en relevancia que los dos servidores JBoss al fallar no tuvieron buen manejo de errores y el servidor se cayó. Mientras que OpenMQ (Glassfish) lanzó una excepción de que no podía seguir recibiendo mensajes pero continuó operativo.

Matt  publicará una segunda parte de su benchmark, así que estén atentos para una continuación.