5

Basically I have one master node that distributes tasks between worker nodes. Number of workers could change, that means that the workers could not be hard coded at the server side. Master submits a task to the queue and one of the workers takes this task, processes it and returns the result back. The most critical aspect is low latency. The typical process time on worker node is about 100-300 ms, this means that messaging system should not add significant delay to the process time.

Currently I'm looking at request-response JMS pattern. This means that master would submit the task to the shared queue, the worker would take the task from the queue and submit the result to another queue which is listened by master node. Master would correlate the response with request.

I'm afraid that JMS may bring latency to the system, which is not acceptable. Probably I should look at other solutions? Such as RabbitMQ, JGroups or ZooKeeper?

If JMS is suitable here, could you recommend the fastest JMS broker? Currently I'm looking at ActiveMQ

One more requirement for the solution is that it should be able to work in the cloud

andrershov
  • 460
  • 3
  • 12
  • If processing a job takes 100-300 ms, the latency of the queue will probably be fairly insignificant in comparison. It shouldn't be hard to get the queue latency down to a couple ms with any of the technologies above. – sbridges Sep 23 '12 at 16:16

3 Answers3

1

A JMS based solution cannot guarantee low latency because of the inherent message batching technique used by all vendors, be it Rabbit or Hornet or ActiveMQ for high throughput. Vendors like IBM and Mule have released specific low latency products for the job.

But everything depends on your load and number of tasks produced and number of workers consuming. So with tuning you can get your personalised numbers.

CoralQueue based on LMAX disruptor is definitely worth a look.

satks
  • 161
  • 1
  • 3
0

You should have a look here [1], Rabbitmq has a good performance article and the talks about latency.

A quick resum, I have to say that Rabbitmq can take 400ms lateny value in some stressed circumstances but usually with low sending rate it is most close to 40ms or fewer. Have a look at (sending rate attempted vs latency graphic)

By the way you should take into account your network latency as well. This benchmark shows a localhost performance.

[1] http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-part-1/

pfreixes
  • 439
  • 2
  • 6
0

I presume you are looking for a Java solution (From JMS)

For hight throughput low, latency in memory queue functionality you could consider Hazelcast (http://hazelcast.org/)

It might do... It depends on how frequently workers will leave/join the cluster. Very frequent Adding / Removing members of a cluster will make it less efficient.

Also, if you require persisted queues or complex queue management, this might also be troublesome.

Non-java clients will be problematic since you will need to purchase a license.

However if you just want a low latency queue for java - it will do the trick

For quick look to see if it will fit your purpose look here: http://docs.hazelcast.org/docs/latest/manual/html/queue.html

Make sure you have a good network config as well. 10gig if you can, 1gig will do but make sure you use a reputable switch.

Max Robbertze
  • 406
  • 4
  • 11