Apples and Oranges: Performance

Superficially, stormmq seems to be like Amazon’s SQS, but they have very different performance characteristics.

This is the first of six articles in the series comparing stormmq and Amazon SQS.

Superficially, stormmq seems to be like Amazon’s SQS, but they have very different performance characteristics.

Amazon SQS is great if you don’t need volume or latency.

Performance. One of those words that comes up time and again in IT, is misused as much as understood and seems to drive decisions a bit too much. In many ways, performance doesn’t matter – at least not to start with. Getting it right matters far more. In that respect, it doesn’t matter if you choose Amazon SQS over stormmq; getting your application out does. However, an understanding of what you’re trying to does.

Amazon SQS is ideal if you:‐

  • need to send and process a few small messages a day;
  • send data that isn’t covered by legal compliance issues;
  • send data that can be occasionally lost;
  • send data where retrieval and processing time isn’t critical;
  • want to use a HTTP based API, is for use from inside a web page or java script client.

If your application can work under these requirements then stormmq would be a poor choice… because Amazon SQS will cost you only a few dollars a month.

However, when transit time is important (‘message latency’), then Amazon SQS starts to look a little different. Using Amazon SQS you can send a message in under a second if you are lucky but it often takes a few seconds. Then when you go to retrieve the message you need to use an incredibly inefficient HTTP poll that wastes bandwidth and CPU resource.

With stormmq we can turn a message around in under 14ms. However, it can seem faster, as we don’t use an HTTP connection for a new message and another one for an ack. Indeed, using a consumer, messages just arrive in the background, for processing. So if you’ve got a long lived app, and need to take action as soon as something arrives, we’re ideal. If you’ve got multiple consumers, we get to become far more efficient, automatically pushing messages where they’re needed.

In terms of performance, stormmq and Amazon SQS don’t compare.


  Raphael ‘Raph’ Cohn

Raphael ‘Raph’ Cohn
Title
Chief Architect
Co‑Founder
Company
stormmq
Phone
+44 (0) 7590 675 756
Email
raphael.cohn@stormmq.com

I’ve designed, developed and burnt the midnight oil on the graveyard support shift from large systems for banks to troubleshooting telcos to pricing electricity in Singapore. The one thing that was always missing was ‘ready to use’ Message Queuing. Message Queues you could set up and tear down yourself without bureaucracy or crazy costs. Message queues that worked with anything. Then it dawned. Message Queuing should be a cloud based service.