7 ms·

Head dev of RabbitMQ response to OpenAMQ's announcement

23 points by liraz 17y ago

seldo 17y ago
This doesn't address 0MQ's performance improvement claims, which I would have thought was the biggest thing the RabbitMQ guys would want to address.
- evgen 17y ago
  If you don't need to provide persistence and flow control it is amazing how much faster you can go...
  - majke 17y ago
    And if you do, things can became pretty complicated.
    - evgen 17y ago
      Absolutely. I happen to need these bits so zeromq is a non-starter for me. I am mildly annoyed by the "we are faster" rhetoric without the "but we only support a small subset of the useful things you can do with a message queue" caveat, but it is a mostly meaningless bit of marketing so I can let it slide; anyone who really needs those sorts of speeds knows how to actually evaluate products and is unlikely to be suckered by a false dichotomy setup like the one on the zeromq home page.
- rabbitmq 17y ago
  It turns out that RabbitMQ's throughput of tens of thousands of transient messages per second per CPU is enough for a lot of cases. Similar story with latency. ZeroMQ does a lot of neat stuff to make it go faster still, e.g taking out the server, and removing all routing info from the messages, but ends up being much more like an alternative to sockets as a result, which makes it less useful for general work. In summary - RabbitMQ and ZeroMQ are complementary, rather than really being alternatives to one another. alexis RabbitMQ
dschobel 17y ago
Not much by way of technical content. Although when the original charge is that the protocol is "fundamentally flawed", I don't know how you can respond specifically beyond saying "it works and people are using it" (which it seems to and which they are).
- moe 17y ago
  You could say: "Yes, you are right. We, too, have noticed what huge pile of hopelessly overengineered garbage it is. Thanks for admitting your own mistake, so glad we can finally get rid of this monstrosity and move on to something sane." This would be the automatic response from anyone who has had the misfortune to work with AMQP, thus I'm a bit baffled the RabbitMQ guys want to stick with it. Edit: And yes, I'm not really surprised that I'm getting modded into oblivion. Still, would the downvoters mind to elaborate on what kind of exposure they've had to AMQP and what part of it they consider worth keeping?
  - wooster 17y ago
    I'm not down-modding you, but I am using AMQP in production on http://tweeteorites.com/ http://tweeteorites.com/ with RabbitMQ. I need persistence and flow control, as my consumers are unreliable and production rate is highly variable. This will become even more important as some of the new Twitter data streams come online. It took me about 2 days to completely reengineer my backend around RabbitMQ and a custom daemon to serve stream requests. Granted, I already had RabbitMQ set up and routing background tasks for celery ( http://celeryproject.org/ http://celeryproject.org/ ), but it's still pretty trivial to set up and get running. The easy case, which I'm at now, is pretty easy, and I've got a good path to scalability with fan out exchanges. That said, faster is better, and I'd be interested in zeromq if they had some of the features I need.
    - sandGorgon 17y ago
      That is actually a very valid question - anyone know the stack similar to rabbitmq server + celeryd , but built around zeromq ?
andrewcooke 17y ago
ok, i am a bit clueless here, but if 0mq has no persistance, how is it reliable (durable)? or, if it's not reliable (durable), isn't this whole debate comparing apples and oranges? [edited to clarify i am talking about durability and not just reliability in the tcp sense]
- rbranson 17y ago
  It is reliable in the sense that it can deliver messages between two peers reliably, like TCP. What you're speaking of is durability.
- dschobel 17y ago
  You are correct, there is no persistence. 0MQ is basically just a step above socket level communications, while obviating all of the tedious BS socket programming forces you to do. Here's a good intro to 0MQ from lwn.net, along with sample code: http://lwn.net/Articles/370307/ http://lwn.net/Articles/370307/
  - andrewcooke 17y ago
    thanks. this seems an awful lot like the nosql "debate" in that the two "sides" (typically) have different priorities (and the differences are similar, related to consistency and scaling). [and also makes imatix not look that good, if any customers need the durability part, which is quite a common requirement]

23 points by liraz 17y ago

seldo 17y ago

This doesn't address 0MQ's performance improvement claims, which I would have thought was the biggest thing the RabbitMQ guys would want to address.

evgen 17y ago
If you don't need to provide persistence and flow control it is amazing how much faster you can go...
- majke 17y ago
  And if you do, things can became pretty complicated.
  - evgen 17y ago
    Absolutely. I happen to need these bits so zeromq is a non-starter for me. I am mildly annoyed by the "we are faster" rhetoric without the "but we only support a small subset of the useful things you can do with a message queue" caveat, but it is a mostly meaningless bit of marketing so I can let it slide; anyone who really needs those sorts of speeds knows how to actually evaluate products and is unlikely to be suckered by a false dichotomy setup like the one on the zeromq home page.
rabbitmq 17y ago
It turns out that RabbitMQ's throughput of tens of thousands of transient messages per second per CPU is enough for a lot of cases. Similar story with latency. ZeroMQ does a lot of neat stuff to make it go faster still, e.g taking out the server, and removing all routing info from the messages, but ends up being much more like an alternative to sockets as a result, which makes it less useful for general work. In summary - RabbitMQ and ZeroMQ are complementary, rather than really being alternatives to one another. alexis RabbitMQ

dschobel 17y ago

Not much by way of technical content. Although when the original charge is that the protocol is "fundamentally flawed", I don't know how you can respond specifically beyond saying "it works and people are using it" (which it seems to and which they are).

moe 17y ago
You could say: "Yes, you are right. We, too, have noticed what huge pile of hopelessly overengineered garbage it is. Thanks for admitting your own mistake, so glad we can finally get rid of this monstrosity and move on to something sane." This would be the automatic response from anyone who has had the misfortune to work with AMQP, thus I'm a bit baffled the RabbitMQ guys want to stick with it. Edit: And yes, I'm not really surprised that I'm getting modded into oblivion. Still, would the downvoters mind to elaborate on what kind of exposure they've had to AMQP and what part of it they consider worth keeping?
- wooster 17y ago
  I'm not down-modding you, but I am using AMQP in production on http://tweeteorites.com/ http://tweeteorites.com/ with RabbitMQ. I need persistence and flow control, as my consumers are unreliable and production rate is highly variable. This will become even more important as some of the new Twitter data streams come online. It took me about 2 days to completely reengineer my backend around RabbitMQ and a custom daemon to serve stream requests. Granted, I already had RabbitMQ set up and routing background tasks for celery ( http://celeryproject.org/ http://celeryproject.org/ ), but it's still pretty trivial to set up and get running. The easy case, which I'm at now, is pretty easy, and I've got a good path to scalability with fan out exchanges. That said, faster is better, and I'd be interested in zeromq if they had some of the features I need.
  - sandGorgon 17y ago
    That is actually a very valid question - anyone know the stack similar to rabbitmq server + celeryd , but built around zeromq ?

andrewcooke 17y ago

ok, i am a bit clueless here, but if 0mq has no persistance, how is it reliable (durable)? or, if it's not reliable (durable), isn't this whole debate comparing apples and oranges? [edited to clarify i am talking about durability and not just reliability in the tcp sense]

rbranson 17y ago
It is reliable in the sense that it can deliver messages between two peers reliably, like TCP. What you're speaking of is durability.
dschobel 17y ago
You are correct, there is no persistence. 0MQ is basically just a step above socket level communications, while obviating all of the tedious BS socket programming forces you to do. Here's a good intro to 0MQ from lwn.net, along with sample code: http://lwn.net/Articles/370307/ http://lwn.net/Articles/370307/
- andrewcooke 17y ago
  thanks. this seems an awful lot like the nosql "debate" in that the two "sides" (typically) have different priorities (and the differences are similar, related to consistency and scaling). [and also makes imatix not look that good, if any customers need the durability part, which is quite a common requirement]