DiRC (funded by Siemens AG)

Performance Evaluation of Architectures for Distributed Real-Time Communication (DiRC)

The Publish/Subscribe Communication Pattern

In publish/subscribe communications, both information providers -- so-called publishers -- and information consumers -- so-called subscribers -- register at a central server. The publishers send messages to the server that forwards them to all subscribers. Optionally, subscribers can install filters on the server that select only a certain subset of messages for them. Currently we study the following problems. 

• There are no or only insufficient performance evaluation studies about the capacity of JMS servers. We tested several types from different vendors and assessed their capacity in different application scenarios, in particular with and without filters. Our measurement results showed that the capacity of the servers ranges over several orders of magnitude depending on the server type and the application scenario.
• Eventing systems in large distributed applications must handle an enormous message rate. The applications often have real-time or quasi-real-time requirements, i.e., the delay observed by the messages at the JMS server must be small. As mentioned above, the service time for messages ranges over several orders of magnitude. We considered different application scenarios to assess a reasonable upper bound on the variation of the service time and derived the waiting time distribution for the messages. The results showed that the waiting time is short even at a high server load of 90% if the server capacity is sufficiently large.
• The capacity of a single server may not suffice to forward the traffic of a large-scale application. Therefore, we look at the performance of server clusters.
• In case of a failure the subscriptions and their information has to be moved to a backup server. The JMS API itself does not provide any methods by default. So each software implementor has to follow an efficient strategy. In case of ActiveMQ we investigate the Master/Slave and a so-called Network of Brokers mode.

The Request/Reply Communication Pattern

However the publish/subscribe communcation pattern provides an efficient one-way and decoupled message transmission in certain cases an immediate response on a send request might be necessary in software archictecture. This client/server based communication is supported by several protocols available in the Internet. We focus on such, that support an seamless exchangable integration and supporting decoupling as provided by the publish/subscribe principle. Esp. in the field of service oriented architectures already exist implementations of application layer protocols, e.g. SOAP. As a key element of these protocols one may focus their interface frameworks, which might introduce additional overhead. As an ongoing research we evaluate and compare the performance of different implementations of these message oriented middleware frameworks.

• One aspect of resarch is the maximum achievable throughput depending on the introduced overhead per message transmission.
• Another performance impact might be introduced by long lasting connections.
• The characterization and a comparable model of the introduced overhead for the different alternatives will support the design of future application.

Links and Literature

General information on publish/subscribe and JMS

• Survey of Publish Subscribe Event Systems (Ying Liu and Beth Plale, CS Indiana)
• Java Message Service Specification

Software products following the JMS API

• Apache ActiveMQ
• Fiorano MQ
• Bea WebLogic
• IBM WebsphereMQ
• jBoss
• OpenJMS
• SunMQ
• ØMQ

Software products appropriate for request/reply communication

• Apache CXF
• Apache Tuscany
• Apache Axis 2
• Sun JAX-WS