JBossDeveloper

Hi,

testing on a rather "low-end" - 2.1 GHz Core  2 Duo - notebook, the testSendAndReceiveMessage test in  StompStressTest.java client needs around 70 milliseconds per message. Same result with ConcurrentStompTest, around 70 msec/msg.

I added

      // before send/receive loops

      long started = System.currentTimeMillis();

      // after send/receive loops, and after assertTrue(latch.await(count, TimeUnit.SECONDS));

      long elapsed = System.currentTimeMillis() - started;
       double msecPerMsg = (double)elapsed / count;     
       log.info("Received " + count + " messages in " + elapsed + " msec,  " + msecPerMsg + " msec/msg");   
       assertTrue(elapsed < count * 50);

If I modify the test code to only send messages, message rate is at 0.5  msec/msg (69.5 msec less than send & receive).

I will do a fresh check out and repeat the test (now I have only deleted the eclipse-ouput folder and rebuilt the project in Eclipse).

The tests with external (Delphi) Stomp clients still show good performance values, between 2000 and 3000 messages per second.

Michael

I have tested it with a fresh check-out, and find the same results.

StompStressTest.java uses auto ack, it does not request receipts:

frame = "SUBSCRIBE\n" + "destination:" + destination + "\n" + "ack:auto\n\n" + Stomp.NULL;

The queue is created non-persistent:

config.getQueueConfigurations().add(new CoreQueueConfiguration(destination, destination, null, false));

At the moment I can see no other reasons why it is slower in the tests than with the external Stomp clients.

Update: it works much better in Linux (Ubuntu) - the 70 msec/msg phenomenon appears on Windows (Vista). On Linux, the concurrent test performs at 2.5 msec/msg.