Message Queuing Product Comparison

It took me a week to evaluate the comparison of various Message Queuing products, which is very interesting. The motivation for me to do this is because a customer has a high performance requirement. Their message information broke through 1 million of concurrent concurrency. They are currently using SQL Server and are not ideal and I recommend that they use a Message Queuing server.

In order to get a comprehensive but superficial understanding of the performance of some similar candidates, we put together a test. I let each message product send and receive 1.001 million 1K messages. The test preparation is a bit hasty, I did not modify any of the configuration, just a quick look at their installation documentation, install each kind of software, and then let them do the simplest to send and receive information operations. So this is a real "out-of-the-box" performance. I fully understand that this is a penalty for Message Queuing products that are very conservative in their initial configuration.

The candidate products are:

　　Msmq

This is the only thing in Microsoft's product that is considered valuable. For my clients, if MSMQ can prove that it can handle such a task, they will choose to use it. The point is that this thing is not complicated, except for receiving and sending, nothing else; it has some hard limits, such as the maximum message volume is 4MB. However, by connecting with some software such as Masstransit or nservicebus, it can solve these problems completely.

　　ActiveMQ

The backbone of the Java world. It has a long history and is widely used. It is also cross-platform, providing a natural integrated access point to products that are not Microsoft platforms. However, it can only be considered if it runs past MSMQ.

　　RabbitMQ

I've heard a lot about this excellent feature of the message middleware written in Erlang. It supports the open Advanced Message Queuing protocol (amqp,advanced message Queuing Protocol), which fundamentally avoids the closure of manufacturers and can benefit from a variety of customers in any language. This protocol provides a fairly complex message transfer pattern, so there is basically no need for masstransit or Nservicebus mates. It also has "enterprise-class" adaptability and stability. These things are very attractive to my clients.

　　ZeroMQ

I discovered this product from the time I was studying AMQP. The company that developed the product is part of the AMQP group and has a product called OPENAMQ. However, they were dramatically separated from AMQP and complained that the product had lost its way and became more and more complex. You can read Dear John's article on the matter here . ZEROMQ has a unique non-middleware model, which means that unlike several other tested products, you don't need to install and run a messaging server, or middleware. You just need to simply reference the ZEROMQ library, you can use NuGet to install it, and then you can happily send messages between applications. Interestingly, they also use this approach to create an Erlang-style executive role in any language that leverages ZEROMQ for powerful in-process communication.

It's an interesting job to put these four MQ products up and running. When you need to install a non-Windows platform product, it is necessary to do a certain amount of effort. ACTIVEMQ requires an Erlang environment to install JAVA,RABBITMQ on the target machine. There is no trouble installing both of these products, but I think this adds a layer of task to the maintenance of the system. If one of these is selected, I need to have the system maintainer understand and maintain the runtime that they were unfamiliar with. ActiveMQ, RABBITMQ, and MSMQ all need to start the service process, which can be monitored and configured, and the other one has a problem.

ZeroMQ, it does not have a middleware architecture and does not require any service processes and runtimes. In fact, your application endpoint plays the role of this service. This makes deployment very simple, but the worry is that you have no place to see if there is a problem. As far as I know, ZEROMQ only provides non-persistent queues. You can implement your own auditing and data recovery capabilities where you need it. To be honest, I'm not even sure if I should put it in this test, it's running in a different way than the others.

I'm not going to be kidding, here's the test results. Displays the number of messages per second sent and received. A total of 1 million 1K messages were generated throughout the process. The execution of the test is performed on a Windows Vista.

As you can see, ZEROMQ and others are not a level. Its performance is surprisingly high. To be fair, ZEROMQ is more like a head beast than the others, though the conclusion is clear: if you want an application to send messages as quickly as possible, you choose Zeromq. It is more valuable when you are less concerned about accidental loss of certain messages.

Frankly speaking, I prefer to use rabbit. But this kind of thing should be done more testing, you will eventually have a favorite, I hear, read all kinds of things about rabbit I think it should be the best choice. But using this test result, it's hard for me to persuade them not to use MSMQ.

If you want to run these tests on your own, my test code is on GitHub . I am interested (but not very very interested) to know how to optimize these tests, so if you can do a better test result, please tell me. Thank you.

Message Queuing Product Comparison