In the previous article in this series, we explored the basics of the three messaging protocols that underlie the different techniques for connecting browser-based applications to RabbitMQ. In this blog, we are going to cover the intricacies of WebSockets and RabbitMQ.
RabbitMQ ships with two plugins that could allow you to communicate with RabbitMQ from the browser: the Web-STOMP and the Web-MQTT plugins.
Web-Stomp Plugin
You can activate the Web-STOMP plugin using the RabbitMQ CLI with
the command:
rabbitmq-plugins enable rabbitmq_web_stomp.
Once enabled, the Web-STOMP plugin would expose a WebSocket endpoint on
port
15674,
which is configurable. This WebSockets endpoint would basically allow your
Rabbitmq server to receive STOMP frames wrapped in WebSockets packets.
But what happens when RabbitMQ receives these WebSockets packets?
The image below visualises that:
Figure 1 - Web-STOMP flow
In the illustration above, steps 1 - 3 outline the actions taken to forward STOMP frames over a WebSocket connection to RabbitMQ. Steps 4 - 6, on the other hand, demonstrate the reverse of what happens if the RabbitMQ server needs to send data to the browser client.
Web-MQTT Plugin
You can activate the Web-MQTT plugin using the RabbitMQ CLI with the command:
rabbitmq-plugins enable rabbitmq_web_mqtt.
Once enabled, the Web-MQTT plugin would expose a WebSocket endpoint on port:
15675,
which is configurable. This WebSockets endpoint would basically allow your RabbitMQ
server to receive MQTT frames wrapped in WebSockets packets. But what happens when
RabbitMQ receives these WebSockets packets?
The image below visualizes that:
Figure 2 - Web-MQTT flow
In the illustration above, steps 1 - 3 outline the actions taken to forward MQTT frames over a WebSocket connection to RabbitMQ. Steps 4 - 6, on the other hand, demonstrate the reverse of what happens if the RabbitMQ server needs to send data to the browser client.
The Gap: AMQP over WebSocket using websocket-tcp-relay
At CloudAMQP, we observed that some of our customers used Web-MQTT or Web-STOMP in their browser-based applications, but used AMQP for other things(and not MQTT or STOMP). Since RabbitMQ doesn't support AMQP over WebSockets natively, we we created the the websocket-tcp-relay.
We developed the websocket-tcp-relay to facilitate AMQP over WebSockets in RabbitMQ. We believed that those who typically use STOMP and MQTT on the web might prefer AMQP if it was available as a web plugin. This is because we believe mastering a single protocol is simpler.
While our primary goal was to enable AMQP over WebSockets in RabbitMQ, the relay can also turn any TCP server into a WebSocket endpoint.
Usage
- The websocket-tcp-relay is installed on all dedicated CloudAMQP instances.
-
Since it is open source, so you can install it on your server as well with
apt.Or you can also run in a docker container. - Find more information regarding installation on the project’s GitHub repository.
So far, we know that, for example, MQTT is a very lightweight protocol and should be more resource-efficient than the others, but how does this convert when used over WebSockets in RabbitMQ? So, we asked ourselves, are the presumptions we have about the performance of these protocols equalise reality?
To explore that, we wanted to know how many connections Web-STOMP, Web-MQTT and Web-AMQP can handle and how much resources they need. In the subsequent sections, we will explore the benchmark setup and our findings.
Web-MQTT vs Web-AMQP vs Web-STOMP: Performance Comparison
As we’ve hinted previously, for the benchmarking, we will be testing these scenarios:
- Connections: The maximum number of connections each protocol can support
- Resource usage: How much memory and CPU each protocol would use when tested with a fixed number of connections
Before we share our findings for each benchmark scenario, first, let’s look at the benchmark setup.
Benchmark Setup
We did set up a 1-to-1 topology between n number of producers (publishers) and n number of consumers (subscribers). Each publisher was publishing messages with an interval of 50-60 seconds.
We created multiple connections from three servers simultaneously. These connections were created against servers running RabbitMQ and either had the Web-STOMP plugin, the Web-MQTT plugin, or the websocket-tcp-relay enabled. The illustration below demonstrates what this arrangement would look like when testing a RabbitMQ server with the Web-STOMP plugin enabled.
Figure 3 - Benchmark server setup
We used multiple servers as load generators to speed up the process since the creation of connections takes some time. But also, to be able to spread out the creation of connections to not load the server too much at a time.
Connections
For the connections test, the Web-MQTT, the Web-STOMP and the Web-AMQP nodes were each hosted on a 2vCPU and 4GiB RAM machine.
The graph below illustrates the maximum number of connections each protocol could support on that small machine.
Figure 4 - Maximum connections per protocol
As one could expect, Web-MQTT could handle more connections than Web-STOMP and Web-AMQP. Web-MQTT could handle around 13,000 connections meanwhile Web-AMQP and Web-STOMP could only handle around 9,000 and 10,000, respectively.
Resource usage
The next thing we did was use servers with more memory, but not testing the maximum number of connections, we instead fixed the number of connections to 15,000 and 20,000.
Here, the Web-MQTT, the Web-STOMP and the Web-AMQP nodes were each hosted on a 2vCPU and 8GiB RAM machine. The graphs below demonstrate the resource usage of each protocol when tested with 15,000 and 20,000 connections respectively.
Figure 5 - Resource usage with 15k connections
Figure 6 - Resource usage with 20k connections
Not surprisingly, Web-MQTT could handle more connections with less memory usage here as well. But the CPU usage isn’t really lower than for the other protocols. Web-AMQP performed well as well.
Conclusion
In this blog series, we delved into how browsers can connect with RabbitMQ using the Web-STOMP and Web-MQTT plugins — supported natively in RabbitMQ. While RabbitMQ does not support AMQP over WebSockets out of the box, at CloudAMQP, we created the websocket-tcp-relay to enable that.
Ready to start using RabbitMQ and WebSockets in your architecture? CloudAMQP is one of the world's largest RabbitMQ cloud hosting providers. In addition to RabbitMQ, we have also created our in-house message broker, LavinMQ - we benchmarked its throughput at around 1,000,000 messages/sec.
Easily create a free RabbitMQ or free LavinMQ instance on CloudAMQP. All are available after a quick and easy signup.
For any suggestions, questions, or feedback, get in touch with us at contact@cloudamqp.com
