NullPersistence service manager performance

[brettcave]

Have just upgraded from messaging-1.4.0-SP3 to 1.4.2-SP1. The performance of 1.4.2 is significantly slower.

The following code is used:

QueueSender sender = (QueueSender) session.createProducer(queueOut);
String correlationID = message.getJMSCorrelationID();
QueueReceiver receiver = (QueueReceiver) session.createConsumer(queueIn, "JMSCorrelationID = '" + correlationID + "'");
sender.send(message, DeliveryMode.NON_PERSISTENT, priority, timeToLive);
connection.start();
result = receiver.receive(resultTimeOut);
connection.stop();

We are using a java library called stompconnect which is used as a broker for another system that picks up messages, processes and returns a response back to jms. The stompconnect environment uses jboss-remoting and jboss-messaging. The 2 libraries were updated as per the doc (using 2.2.2-SP11 of jbr and 1.4.2-sp1 of jbm). These libraries are also added to the jboss lib directory.

The following is an indication of timings (10 requests)

JBM-1.4.0-SP3 mysql-persistence: min: 17ms, max: 40ms, avg: 28ms
JBM-1.4.2-SP1 mysql-persistence: min: 24ms, max: 24ms, avg: 24ms
JBM-1.4.2-SP1 null-persistence: min: 28ms, max: 58ms, avg: 39ms

[brettcave]

DefaultDS used in mysql-persistence cases uses a sql server on the network (1gbps). messages are sent as NON_PERSISTENT

Why would null-persistence be running slower?

[timfox]

You should explain what your test does and what your results mean.

[brettcave]

The timing metrics are measured internally by the EJB that contains the method to send the message to JMS.

A message is generated by our application. This message is passed to the method above.
A JMS producer is initialised.
A message correlation ID is generated from the message.
A JMS consumer is initialised.
The message is sent to the jms provider (jbm), flagged as non-persistent.
stomp connect is running (bisocket) and a native app (C) receives the message, performs some actions, and then sends a response back to JMS via stompconnect, where the EJB that initially sent the message receives the response.

The response message contains the timing of the native app, and the EJB then subtracts this time from the total timing.

So the results posted are basically for initalising the producer, generating / getting the correlation ID, sending the message until the message hits the app, and then from the message being sent back to JMS until it is received by the EJB.

The results basically are showing the timing differences between JBM 1.4.0-SP3 configured with mysql-persistence (even though messages are sent as non-persistent), JBM 1.4.2-SP1 with mysql-persistence and JBM 1.4.2-SP1 configured with null-persistence.

Trying to understand why null persistence configuration consistently has significantly higher latency than mysql persistence configuration, even though messages are always marked as non-persistent.

[timfox]

10 requests is nowhere near enough for this to be statistically significant.

You should try again with several thousands (or 10s of thousands) of requests.

Let the test run for several minutes before taking results.

[brettcave]

setting up jmeter for substantial testing.