Messaging Performance UME
With UME's many unique design features including its ability to eliminate stores as bottlenecks and the fact that UME does not delay the sending of messages while waiting for stability notification (yet still ensures that messages are to be stable on the store), UME solutions are able to deliver message rates that were not possible using legacy persistent messaging designs. The UME design does not require a write to a store before messages can be sent to the end destination, but rather allows the persistent write to the store and the write to the end receiver to run in parallel. These design features decrease latency and provide dramatic gains in throughput when compared to existing designs.
The Result
The result of using UME for your messaging platform is simple yet significant: you are provided with a high performance, low latency persistent messaging platform that sheds the extra steps & processes typically found among application messaging exchanges, thereby significantly lowering latency and resulting in a true application-to-application product.

The data was collected using a pair of machines with the following specs:
- Intel Core 2 CPU 6600 @ 2.40 GHz
- 2GB RAM
- Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express
- Linux RHEL 4
- Testing was done using LBM 3.0 and UME 1.1.
- Data was gathered using LBMPong and a modified version or LBMPong called UMEPong which connects to a UME stored daemon. LBMPong and UMEPong gather message round trip times (RTT). One-way latencies are reported as one-half of the RTT reported by LBMPong and UMEPong using a TCP transport.
- LBMPong/UMEPong operate by bouncing a message back and forth between two end points and reporting an average RTT over a given number of iterations. Data was collected using four different message sizes (25, 1024, 4096, and 16384) with an iteration count of 10,000. Each individual test was repeated three times. Message sizes > 1024 are fragmented at the IP layer. The 16384 bytes message size is also fragmented/reassembled by LBM/UME itself.
- UME tests were run in three different modes:
- Without durable subscription
- With durable subscription
- With durable subscription and confirmed deliver
- The collected data shows virtually no difference in latency between LBM and UME without durable subscription and no difference between UME with and without confirmed delivery.