Many enterprises rely on traditional, commercial messaging systems for their most critical applications. Often, these systems use the Java Message Service (JMS) API, particularly for Request/Response (RPC) patterns. While reliable, these legacy platforms can be expensive, are proprietary, and represent a form of “legacy lock-in” that can prevent adoption of modern architectures.
You might be asking: “We want to modernize, but can a modern, open source platform really handle our specific, high-demand workload?” The VMware Tanzu team recently partnered with a customer to answer that very question. The customer wanted to migrate their existing JMS-based system from a traditional, proprietary broker to VMware Tanzu RabbitMQ. But first, we needed to validate that Tanzu RabbitMQ could handle their workload, which wasn’t a simple use case; it involved a massive-scale RPC workload with extreme connection churn.
This scenario is a perfect stress test for any modern messaging broker, and it’s a story we think many architects and IT leaders will find familiar.
The challenge: A “perfect storm” of a workload
To understand the challenge, let’s review the customer’s environment as they described it, in their own words. This is not a typical workload with a few dozen long-lived connections. This is a high-throughput system defined by ephemeral processes.
Here’s what we had to replicate:
- Massive connection churn – The application setup could create up to 20,000 parallel connections. Crucially, each of these connections is short-lived; the system establishes a new connection for every single request/response operation.
- High throughput – The system processes 4 million–6 million requests daily on average, with volatility driving that up to 20 million (or even 50 million in some estimates).
- Extreme peak rates – During bursts, the system must handle up to 8,000 requests per minute, with a peak requirement of 4,000 requests per second on a single queue.
- The pattern – The application uses the classic JMS Request/Response pattern, where a client sends a request and waits for a response on a temporary queue.
This combination of 20,000 simultaneous connections and constant connection/disconnection (churn) at a rate of 4,000 per second is the ultimate test of a broker’s connection-handling capabilities.
The test: Simulating churn at scale
Our goal was to validate the workload as described by the customer and prove that Tanzu RabbitMQ could not only handle this load but do so with ease.
We didn’t just run a simple benchmark. We wrote a dedicated RPC performance tool for the occasion to precisely simulate this high-churn environment. We set up a three-node Tanzu RabbitMQ cluster and configured it to handle a large number of connections using well-documented tuning settings.
One key Tanzu RabbitMQ feature that’s perfect for this RPC use case is the direct reply-to optimization. This mechanism allows a client to receive a response directly without the overhead of creating and managing thousands of temporary queues, which is a common bottleneck in other systems.
We ran two main scenarios:
- Baseline test – First, we established a baseline with 20,000 long-lived connections (no churn). The cluster easily handled 20,000 requests per second. This was a good start.
- The real-world churn test – This was the main event. We spun up clients to create 20,000 simultaneous connections, with each client connecting, sending one request, receiving a reply, and disconnecting. We aimed for the customer’s peak of 4,000 requests/sec and then pushed it 25% higher to 5,000 requests/sec.
The result: Validation confirmed
The results of our validation test were definitive. Under the extreme load of 20,000 simultaneous clients, the three-node Tanzu RabbitMQ cluster successfully sustained the 5,000 request/response operations per second—even when every single request involved a new connection and disconnection.
This initial test gave a clear indication that RabbitMQ could handle the demanding workload.
But the story doesn’t end there. We’re excited to share that subsequent tests run by the customer on their own systems are yielding positive initial results. In these validations, RabbitMQ successfully sustained their load, suggesting it is a strong and viable choice for their production environment.
Beyond JMS: Your gateway to modernization
Here’s the most important takeaway: Tanzu RabbitMQ isn’t just a cheaper, modern replacement for your legacy broker. It’s an upgrade for your entire architecture. Tanzu RabbitMQ can reliably handle your existing JMS workload, giving you an immediate path to modernize and reduce costs.
But that’s just the beginning. Migrating to Tanzu RabbitMQ can unlock a much wider ecosystem:
- Protocol flexibility – With applications no longer locked into just JMS, you can gain native support for AMQP 0.9.1, AMQP 1.0, MQTT, STOMP, and more.
- Modern data patterns – You can start using powerful features like Tanzu RabbitMQ Streams for high-throughput, “replayable” event logs, moving beyond simple RPC.
- Evolve your architecture – That legacy RPC application can now start to evolve into something more modern or elaborate. You can introduce new microservices written in any language (not just Java) that consume the same data, enabling a gradual, safe transition to a true event-driven architecture.
Don’t let legacy systems dictate your future. Tanzu RabbitMQ provides a proven, low-risk path to migrate even the most critical JMS applications, giving you the reliability you need today and the flexibility you’ll want tomorrow.
