We are currently evaluating JMS solutions. One of our evaluation criteria is the latency introduced by the broker. We measure latency like this:

(no persistence, no durables)

TestClient ->>>JMS Server ->>>TestServer
TestClient <
The Test Client sends a message on a topic and waits for a response on a reply topic from the server. We measure the time between the send and acknowledge on the client with a high resolution timer.

 We are looking for a JMS messaging solution with latency under 1 millisecond.

Forgot to mention, msg size is 100 bytes, Network is GigE

John,

I have no definite figures I'm afraid, but TIBCO have always had the reputation for being the most performant MOM (tho also amongst the priciest). Their JMS solution is called EMS. It is used alot for handling market trading transactions in large financial institutions.

But my other comment is, are you really interested in flatout speed, or scalability? High performers may not perform so well when the load increases, so having an good architecture that supports scalability is important.

I have used MQSeries in the past and IMO it was the best mix of speed, scalable architecture and features. But again, no numbers, sorry!

HTH
Kit

Yes, we have found Tibco's EMS meets our requirements but as you point out, also very pricey which is also an important consideration.

We are most interested latency. We can acheive throughput with static partitioning if a particular product does not scale well.

We about to look at Sonic and Fiorano.

Performance of JMS providers depends on many factors. My advice is always to test a few providers on your architecture to see what performance is in your environment.

One thing that will affect latency is the number of inter-process hops required. e.g. provider's like TibCo's EMS your client talks to a daemon that talks to the network that talks to the server - so there's quite a few hops.

You might want to consider one of the pure Java JMS providers then you can host a JMS server inside your TestServer to minimise hops and reduce latency.

e.g. you could try the open source ActiveMQ

BTW ActiveMQ has an open source JMS benchmark suite
http://activemq.org/JMeter+Performance+Tests

which might be useful. Admittedly it mostly focusses on testing throughput rather than request-response latency - but you might be able to modify the suite to test what you need.

James
LogicBlaze