Benchmarking Message-Oriented Middleware – TIB/RV vs. SonicMQ Michael Pang♣ and Piyush Maheshwari School of Computer Science and Engineering The University of New South Wales Sydney NSW 2052, Australia e-Mail: Abstract Message-oriented middleware (MOM) has become a vital part of the Enterprise Application Integration (EAI) projects. This is because it can be used to pass data and workflow in the form of messages between different enterprise applications. The performance o
of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
   Benchmarking Message-Oriented Middleware – TIB/RV vs. SonicMQ Michael Pang ♣ and Piyush Maheshwari School of Computer Science and EngineeringThe University of New South WalesSydney NSW 2052, Australiae-Mail:   ♣   Now working with SAP Australia. E-mail:   Abstract  Message-oriented middleware (MOM) has become a vital part of the Enterprise Application Integration (EAI) projects. This is because it can be used to pass data and workflow in the form of messages between different enterprise applications. The performance of EAI greatlydepends on how effectively the MOM performs. This paper  presents a benchmark comparison between two industrywell-known MOMs  – Tibco Rendezvous (TIB/RV) and Progress SonicMQ. Although the two MOMs are verysimilar in certain aspects, their native implementation and architecture are very different. We provide an unbiased benchmark reference to the middleware selection process.The primary objective of our work was to evaluate the MOMs by testing their effectiveness in the delivery of messages in publish/subscribe and point-to-point messagedomains, their program stability and the system resourceutilization. 1. Introduction 1.1. What is MOM? MOM is a specific class of middleware that supports theexchange of general-purpose messages in a distributedapplication environment (Figure 1). MOM systems ensuremessage delivery by using reliable queues and by providingdirectory, security, and administrative services required tosupport messaging. Figure 1: Message-Oriented Middleware By sending the messages asynchronously, the sender of aMOM message does not have to wait for anacknowledgement from the receiver. It can simply send themessage and continue with other processes. Rather thanconnecting directly to a remote objects, the program passesthe message via connection to the MOM which then sendsthe message to the receiving application. 1.2. Two Messaging Models 1.2.1. Publish and Subscribe <pub/sub> (One-to-Many) The sender is called the  publisher  and the receiver is calledthe subscriber  . One producer can publish a message tomany consumers through a virtual channel called a topic .Consumers can choose to subscribe to a topic they areinterested in. Any messages addressed to a topic aredelivered to all the subscriber of that topic. Figure 2: Publish/Subscribe Model   [1]Figure 3: Point-to-Point Model   [1]  Every consumer receives a copy of the message beingpublished. This is called a  push-based  model, wheremessages are automatically broadcast to consumers withoutthem having to request or poll the topic for new messages.A published message is received by all interested parties,and parties can subscribe and unsubscribe at will.Publish/subscribe works similarly to signing up for anemail distribution list. 1.2.2. Point-to-Point <PTP> (One-to-One) In the point-to-point arrangement, there is typically a singlesender and a single receiver. This can be done eithersynchronously or asynchronously via a virtual channelcalled a message queue.In this paper, we compare industry well-known MOMs –Tibco Rendezvous (TIB/RV) and Progress SonicMQ.Although the two MOMs are very similar in certain aspects,their native implementation and architecture are verydifferent. This paper provides an unbiased benchmark reference to the middleware selection process. The primaryobjective of our work was to evaluate the MOMs by testingtheir effectiveness in the delivery of messages inpublish/subscribe and point-to-point message domains,their program stability and the system resource utilization.The rest of the paper is organised as follows. Section 2discusses the two MOMs presented in the paper. Section 3discusses the benchmarking issues and system tuning.Section 4 gives a brief description on the tests we haveimplemented for the benchmarking purpose. Finally,Section 5 presents the results obtained from the tests andalso provides a detailed analysis. 2. Benchmarking the MOMs This section introduces the two MOMs, TIBCORendezvous and Progress SonicMQ. 2.1. TIBCO Rendezvous (TIB/RV) TIBCO has been one of the leading providers of EAI sinceits establishment 20 years ago and TIB/RV is one of themost widely used messaging middleware in enterprises.  2.1.1. Architecture TIB/RV is based on a distributed architecture [2]. Aninstallation of TIB/RV resides on each host on the network.Hence it eliminates the bottlenecks and single points of failures could be handled. It allows programs to sendmessages in a reliable, certified and transactional manner,depending on the requirements. Messaging can be deliveredin point-to-point or publish/subscribe, synchronously orasynchronously, locally delivered or sent via WAN or theInternet. Rendezvous messages are self-describing andplatform independent. Figure 4 below represents the mainarchitecture of TIB/RV. Figure 4: TIB/Rendezvous Operating Environment  2.1.2. Components TIB/RV is composed of three main components:   RV Daemon (RVD) responsible for the delivery of messages within a LAN.   RV Agent  (RVA)   RV Routing Daemon (RVRD)  2.1.3. RV Daemon (RVD) Figure 4 shows the architecture of RV in a LANenvironment. Notice how the RV Programs A, B and C,connect to RVD through TIB/RV API, and the RVD isconnected to the network. RVD listens to the network forevery message intended for the programs.The RV daemon arranges the details of data transport,packet ordering, receipt acknowledgment, retransmissionrequests, and dispatching information to the correctprogram processes. The daemon hides all these details fromTIB/Rendezvous programs. RV programs create themessage users want to send, and passes it onto RVD, whichis then responsible for passing them to the destination(s).RVD is a background process that sits in between the RVprogram and the network. It is responsible for the deliveryand the acquisition of messages, either in point-to-point orpublish/subscribe message domain. It is the most importantcomponent of the whole TIB/RV.Theoretically, there is an installation of RVD on every hoston the network. However, it is possible to connect to aremote daemon, which sacrifices performance andtransparencies.  2.1.4. How does a message get to its destination? Publish/Subscribe (One-to-Many)Figure 5: Reliable Multicast Message [3]  Figure 5 shows how messages are publish/subscribe in aLAN environment with the use of RVD. The RV Senderprogram passes the message and destination topic to RVD.RVD then broadcasts this message using User Data Packet(UDP) to the entire network. All subscribing computerswith RVDs on the network will receive this message. RVDwill filter the messages which non-subscribers will not benotified of the message. Therefore only subscriberprograms to the particular topic will get the messages. Point-to-Point (One-to-One)Figure 6: Point-to-Point Messaging in TIB/RV In TIB/RV, point-to-point messages are fairly similar topublish/subscribe, only in a one-to-one model instead of one-to- many. The receiver creates a unique “inbox name”that establishes an address for receiving point-to-pointmessages. To send a point-to-point message, the sendingprogram must know the inbox name of the destination. Thereceiver makes its inbox name known by multicasting it topotential senders using a prearranged subject name.Once the sending program receives the recipient’s inboxname, it will broadcast the message with inbox name as thetopic to the network using UDP. The recipient’s RVD willbe able to receive the message when it realised the topic isit’s own unique inbox name. 2.2. Progress SonicMQ SonicMQ is one of the newer MOMs in the market. Itclaims to be the first JMS implementation, and hasoutstanding performances competitive with existing MOMtechnologies, such as IBM MQSeries. SonicMQ is writtenin 100% pure Java, supports XML messaging, and HTTPtunnelling to allow SonicMQ to work over the Internet.The underlying mechanism of SonicMQ is its “broker” thatfacilitates the movement of messages across the network. Itis a Java executable that requires Java Virtual Machine(JVM) to run.The communication protocols that can be used withSonicMQ include TCP, HTTP and SSL. Since it usescommon Internet protocol, SonicMQ can extend itsdeployment to the Internet. It also provides bridges to manyother popular MOMs that allow messages to be sent andreceived between SonicMQ and other MOMs.  2.2.1. Architecture There are three types of configurations a user can choosefrom:  Single-broker Configuration Under this configuration, there is one brokerwhich is being shared across a few nodes.   Multi-broker Clusters   Multi-node Configurations Figure 7: SonicMQ Single Broker Hub-Spoke Model Figure 7 shows a single broker configuration. The broker isthe most important underlying implementation of SonicMQ. It is responsible for delivering and acquiring of messages within a LAN environment. It is a client-servermodel, where many clients connect to a single broker. Theconnection can be via TCP (for LAN), SSL (for securityencryption), or even HTTP (to connect to external entities).The downside with single broker configuration is thatscalability is limited by the capabilities of the nodemachine. Also the system is dependent on the single brokermachine (node), hence leading to a bottleneck of the systemat the node. The whole system may collapse if the nodegoes down. To solve this problem a multi-broker clustermust be used.  2.2.2. SonicMQ Performance There exist a benchmark report for SonicMQ by ProgressSoftware [5]. SonicMQ showed outstanding performancescompared to IBM MQSeries and Fiorano FioranoMQ, (bothare JMS implementations) under WinNT platform. 2.3. TIB/RV vs SonicMQ Functional Summary The functional features for TIB/RV and SonicMQ are listedin the table below for comparison:    TIB/RV   SonicMQ Underlying MessagingmechanismRVD BrokerPublish/Subscribe yes yesPoint-to-Point yes yesSubject-basedAddressingyes noLocation Transparency yes noSynchronousMessagingyes yesAsynchronousMessagingyes yesGuaranteed MessagingCertifiedMessagingDurableMessagingFault Tolerance yes yesWAN/Internet Support RVA/RVRDDynamicRoutingArchitecturePersistent MessagingLedgerStoragePersistent 3. Benchmarking In order to find out how well a distributed messaginginfrastructure performs under heavy load with a number of concurrent connections, a benchmark test must beundertaken. This section discusses the issues concernedwith planning and deployment of such a complex task. 3.1. Aims of this Benchmark Report The aim of the benchmark tests performed is to determinethe following:1. The effectiveness of the MOMs – messages per second(MPS)2. The time taken for a batch of messages to be delivered3. The effects of increasing the number of publisher andsubscriber connections in a pub/sub scenario4. The effects of increasing the number of sender andreceiver pairs in a PTP scenario5. The effects of constant publisher/sender as opposed to aperiod publisher/sender6. The memory and CPU utilization of the MOMsThese objectives are achieved by:  Writing some Java programs using the APIs provided bythe MOMs  Using a Linux system utility “top” to monitor memoryand CPU utilization of different processes in thesystem. 3.2. Benchmark Environment The following is the environment utilized to perform thebenchmark: 1x Server: Intel Pentium III 450processor196Mb SDRAM13G IBM IDE Hard disk  1x Client: AMD K6-850 Processor256Mb SDRAM30G IBM ATA Hard disk   3.2.1. Network Connection Network Interface: 10BaseT NE2000 compatiblenetwork cardCable: Twist PairLength of cable: Each 1-meter.Hub: RJ45 5 Port Hub  3.2.2. Operating System Mandrake Linux 8.1 – 2.4.8-2 version Kernel 4. Test Description This section describes the Java programs we haveimplemented for testing the two MOMs. The programs forTIB/RV use TIBCO’s own Java API, and the programs forSonicMQ use JMS API developed by Sun Microsystems.As the programs are developed with different APIs, we hadto make special effort to ensure the programs for the sametest are as similar as possible to yield comparable results.Each test aims to evaluate different issues relating toMOMs.Different scenarios are constructed to evaluate the MOMs.Tests 1 and 2 assume a constant producer of messages i.e.the MOMs are always busy throughout the entire testduration. We measure the pub/sub rates and PTPsend/receive rates which represent the behaviour of theMOMs to such environment.As discussed previously, different MOM programs have tomake different procedures to start up and connect to theMOM. Thus, Test 3 measures the connection time of thesubscribers. Finally, Test 4 attempts to measure thememory and CPU utilization of the two MOMs.Each of these tests was tested with different inputparameters, e.g., changing message size, number of message producers and consumers, etc. 4.1. Test 1 – Publish/Subscribe Fixed and Test 2 –Point-to-Point Fixed Tests 1 and 2 aim to measure the publish/subscribe and thepoint to point messaging rate of the MOMs. Message Domain: Publish/Subscribe and Point to Point Description: The sender and receiver programs measurethe rate to publish and subscribe a fixed number of 
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks