This post explores messaging systems and whether or not they perform up to par.
Messaging systems are probably the most reliable technology available for ensuring digital message delivery. This often makes them an integral part of applications that rely on accurate delivery of messages. Factor in the requirement for high-performance and—tadaa!—you’re looking at a mission-critical component.
What’s the use-case?
There are in fact two use cases. The first use case is when losing messages is not an option; for example when submitting customer orders from your online shop to your ERP system (copying and pasting orders from emails is no fun after all). It makes no difference whether delivery takes 50ms or two minutes (for example, because some VPN tunnel is down), the important point is that the order data is successfully delivered into the ERP system. Message queues that offer persistence are designed for just this sort of use case.
The second use-case is when you need a queuing mechanism. You have some input queues and some output queues. In between there’s a high-performance business logic processor that reads from the input queues, performs the required processing, and writes to the output queue. In such cases it’s of absolute importance that the queues provide as high-performance read and write operations as possible. Diverse fallback and journaling mechanisms may take care of reliability and replayability, so persistence is not the primary requirement of queueing systems here.
Message queuing in the wild
Whatever your requirements (guaranteed delivery, high performance, or both), you definitely need to know if your queues are available and how they’re performing.
Ruxit can baseline and monitor your message queuing services like any other service, enabling AI-based problem notifications, problem correlation, and root cause analysis. The way Ruxit presents all necessary information is possibly even more valuable. The screenshot above shows the number of messages, response times, and failure rates.
Response time analysis
In cases where a messaging service doesn’t perform as expected, Ruxit offers deep insight into all aspects of the service. Have a look at an example:
Very likely, your service does more than just interact with the queue. It also handles incoming data (HTTP requests, reading from a database, etc), which it either sends to the queue immediately, or it processes (or at least forwards) the data.
The above screenshot shows that Ruxit measures the interaction times of your service with other components, be they other services, queues, databases, or whatever. In this way you can easily identify all bottlenecks. Ruxit’s ability to drill down to the database level by displaying SQL statements (or, in the case of MongoDB, JSON data) and to the code level, leaves no unanswered questions as to where potential problems reside.
More about high-performance JMS
Oracle offers a short guide on Writing High Performance and Scalable JMS Applications and you should also definitely check out Mark Richard’s High Performance Messaging article.
While related more to high performance business logic processors than messaging, Martin Fowler’s The LMAX Architecture article examines a system that’s built on the JVM platform and centers on a business logic processor that can handle 6 million orders per second on a single thread. Of all the great posts written by Martin Fowler, this is probably my favorite.
Do you know how your messaging services perform?
Ruxit automatically detects the most common JMS compliant messaging systems (i.e. RabbitMQ, ActiveMQ, HornetQ, JBossMQ), EJB message-driven beans and RabbitMQs consumer-plugin interface. You’d definitely want to know about their performance in your environment. If not done yet, I suggest you simply execute Ruxit’s one-click installer (or, in case of Linux: just copy/paste the according wget command) and see the metrics appear on your dashboard within just a couple of minutes. Sign up, it’s free! No credit card required!