[rabbitmq-discuss] fastest way to process messages?

Jon Brisbin jon at jbrisbin.com
Fri Jul 9 21:43:20 BST 2010

I pushed a rough draft/alpha version of the asynchronous distributed cache I blogged about last week to GitHub. It works pretty well for a rough draft. I am noticing some pretty large variances in my metrics from one run to another, though. I'm throwing 25 messages at a time at an object with 25 workers waiting for those objects (so there's no waiting for objects to be processed). I'm seeing run times as fast as 10ms and as slow as 150-200ms. It really varies from one run to the next.

I'm sure there are bottlenecks in my code. I'm starting to investigate that right now. But I was wondering if there was some consensus on maximizing throughput (using the Java client). Since this is a cache, I'm wanting to keep load times to an absolute minimum (duh). In several runs, I've gotten down to 10-15 ms but I can't get it to do that consistently.

Will I be able to process more messages if each of my workers has its own queue, but binds to the exchange using a common key--or should I do what I'm currently doing, which is to use the QueueingConsumer and simply use multiple workers to pull messages off the single BlockingQueue? Which has the potential for higher throughput while not increasing the likelihood I'll end up with duplicate messages?

Is there a better way to process messages if performance is the primary consideration than using the QueueingConsumer? I've haven't looked at the code to see what it's doing, but I would think fewer method calls between delivery of the message and calling the callback provided by the application code would give me greater throughput and shorter run times.

I should probably also investigate alternative languages. I started this as a Java object cache, so naturally I used Java. But I'm wondering if I could get better performance by skipping the serialize/deserialize step in the cache provider (I'm storing actual objects in memory rather than the byte array, which I considered doing at first).

Have a good weekend!


J. Brisbin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100709/138d385b/attachment.htm>

More information about the rabbitmq-discuss mailing list