Big competition (transfer) of Message Queue software products)

Transferred from: It comment of external journals

I spent a week evaluating and comparing various Message Queue products, which is very interesting. I am motivated to do this because a customer has a high performance requirement. Their message information broke through 1 million concurrent messages. Currently, they use SQL Server, which is not ideal. I suggest you use the Message Queue Server.

To gain a comprehensive but superficial understanding of some similar candidate products, we put them together for a test. I have each messaging product send and receive thousands of 1 K messages each. The test preparation was a little hasty. I didn't modify any configuration, But I quickly read their installation documents and installed each software, then let them do the simplest operations to send and receive information. Therefore, this is a real out-of-the-box performance. I fully understand that this will be a penalty for those Message Queue products with very conservative initial configurations.

Candidate products:

• MSMQ.
  This is the only thing that Microsoft products think is valuable. For my customers, if MSMQ can prove to be able to cope with such a task, they will choose to use it. The key is that this is not complicated, except for receiving and sending. It has some hard limits, for example, the maximum message volume is 4 MB. However, by connecting to software such as masstransit or nservicebus, it can completely solve these problems.
• Activemq.
  The backbone of the Java World. It has a long history and is widely used. It is also cross-platform, providing a natural integration access point for non-Microsoft platform products. However, it can be considered only when MSMQ is run.
• Rabbitmq.
  I have heard a lot about the outstanding features of the message-oriented middleware written in Erlang. It supports the open Advanced Message Queue Protocol (amqp, Advanced Message Queuing Protocol), which fundamentally avoids the closure of the manufacturer and can benefit customers in any language. This Protocol provides a very complex message transmission mode, so it basically does not require the cooperation of masstransit or nservicebus. It also has "enterprise-level" adaptability and stability. These things are very attractive to my customers.
• Zeromq.
  I found this product when I was studying amqp. The company that developed this product is part of the amqp group, and there is also a product called openamq. However, they separated amqp dramatically and complained that the product had lost its way and became increasingly complicated. Here you can read dear john's article on this matter. Zeromq has a unique non-middleware model, that is, unlike several other tested products, you do not need to install or run a Message Server or middleware. You only need to reference the zeromq library, you can use nuget to install, and then you can happily send messages between applications. Interestingly, they also use this method to create an Erlang-style execution role in any language that uses zeromq for powerful in-process communication.

It is interesting to install and run these four MQ products. When you need to install a non-Windows platform product, it is necessary. Activemq needs to install Java on the target machine, and rabbitmq needs the Erlang environment. There is no trouble in installing these two products, but I wonder if this adds a layer of task for system maintenance. If one of them is selected, I need the system maintenance personnel to understand and maintain the runtime libraries they were not familiar with before. Activemq,
Both rabbitmq and MSMQ need to start the service process, which can be monitored and configured. The other one is faulty.

Zeromq, which has no Middleware Architecture and does not require any service processes and runtime. In fact, your application endpoint plays this role. This makes the deployment very simple, but you have nothing to worry about. As far as I know, zeromq only provides non-persistent queues. You can implement your own audit and data recovery functions as needed. To be honest, I'm not sure if I should include it in this test. Its running principle is much different from other ones.

I will not talk about it. The following is the test result. Displays the number of messages sent and received per second. The entire process generates 1 million 1 K messages. The test is executed on Windows Vista.

As you can see, zeromq and others are not at the same level. Its performance is surprisingly high. To be fair, zeromq is similar to other giants. Even so, the conclusion is clear: if you want an application to send messages faster, the better, you choose zeromq. It is more valuable when you are not very concerned about accidental loss of some messages.

Honestly, I prefer rabbit. But this kind of thing should be tested more, and you will eventually have a favorite. What I have heard and read about Rabbit makes me think it should be the best choice. However, using this test result makes it hard for me to persuade them not to use MSMQ.

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

Big competition (transfer) of Message Queue software products)