Sun Java System Message Queue Software Performance Tuning: An Overview

This article's purpose is to help developers and administrators using Sun ONE Message Queue software understand how to develop and deploy applications that meet performance requirements. A brief explanation of the software is provided, and aspects that affect performance are highlighted.

Readers need a basic understanding of the Sun ONE Message Queue software system. This article is the first in a series that offers follow-on technical information on how to tune specific aspects of the Sun ONE Message Queue software system.

What is Sun ONE Message Queue Software?

Sun ONE Message Queue software is a middleware technology that provides support for reliable messaging between applications. It implements the Java Message Service (JMS) technology standard. Application developers use this technology in their programs to send messages to other applications. JMS technology provides a common way to send messages in a distributed environment.

The JMS provider for the Sun ONE Message Queue software has three components:

• The client API that implements the JMS APIs

• The broker (a message server)

• The administration component that provides both a command-line interface and GUI-based tools

An application developer uses Sun ONE Message Queue software's implementation of the JMS APIs to produce or consume messages at a destination. The client-side implementation then sends produced messages to the Sun ONE Message Queue broker. The broker routes and sends the messages to the applications designated to receive them.

Defining Performance Tuning

Performance tuning is an iterative process of both developing an application that uses Sun ONE Message Queue software and configuring the software system to meet performance goals. Other aspects of system performance, such as tuning an operating system, are important but covered in other literature. Those aspects, therefore, are not covered here in depth.

Aspects of Performance Tuning and Why They Are Important

Designing a system to meet performance needs should start during the initial requirements stage of application design and continue through deployment. Designing consists of four stages:

• Defining the system's performance requirements

• Developing an application with those requirements in mind

• Benchmarking and tuning the system

• Deploying the system

Defining the requirements allows the developer and administrator to understand what aspects of the system need to be optimized. It also identifies the minimum system requirements during development and the type of performance numbers that are needed during benchmarking and tuning.

At development, design decisions can have a significant effect on overall performance. For example, sending persistent messages is much slower than sending non-persistent messages. If performance is an issue, the developer should take care to make persistent only the messages that must be reliably delivered if the provider fails.

Benchmarking and tuning allow developers to determine if the application meets their original requirements and if not, make changes in the configuration of the system to try to reach the performance goals. Tuning is a process of altering configurable parameters in the broker. The change in performance based on a tuned parameter depends on several factors, including other tuning parameters, hardware, and the composition of messages flowing through the system. A benchmark allows the exact effect of a change or a set of changes to be concretely determined.

During and after deployment of the system, the administrator can make decisions about improving the system performance of the hardware on which the Sun ONE Message Queue software broker is running. The administrator can also obtain metrics information from the broker and use that information to tune the system.

Defining System Performance Requirements

Before developing or tuning an application, the developer may want to consider issues that affect performance or performance requirements. Such issues include:

• The average and maximum instances of applications simultaneously using Sun ONE Message Queue software

• The maximum number of messages passing through the system from all applications at one time

• Latency requirements

• Operating system and hardware restrictions

• Reliability requirements for message types. Developers may ask questions such as:

  • Do the messages need to survive a provider failure?

  • Can the system handle redelivery of messages?

• The store used for the database (file versus JDBC API)

• On the client side:

  • Protocols used (HTTP, SSL, TCP)

  • Connection speed (WAN, LAN)

  • Available resources (memory, CPU)

Developing Applications

Decisions made during development directly impact the performance of applications using Sun ONE Message Queue software. These decisions involve trade-offs such as:

• Delivery mode (persistent versus non-persistent messages). Persistent messages are slower than non-persistent, but are more reliable.

• The appropriate store for the persistent messages. A file-based store is significantly faster than a shared database, but is less reliable.

• Acknowledgment mode. Dups OK acknowledgment mode improves performance, but may result in extra messages being redelivered after provider failure.

• Transactions. A group of message operations (producing or consuming) can be processed (or thrown away) as a single group. However, the production or consumption of messages is slower because of the additional overhead of tracking the transaction state.

• Selectors. Messages can be targeted based on header information for specific consumers; however, performance is decreased.

• Message size. Larger messages take longer to send, although the basic overhead for processing a message is a constant. By batching several smaller messages into a single larger message, the overall performance may be faster. However, the broker will not reliably track the state of the individual messages.

Benchmarking and Tuning

During the tuning and benchmarking stage, administrators can:

• Adjust the system to improve:

  • The performance of the protocols (TCP, SSL, HTTP) used to communicate with the broker

  • The responsiveness of the file-based persistent store

• Tune:

  • The Java Virtual Machine used by the broker

  • Round-robin queue performance

• Adjust:

  • How often the system purges expired messages

  • Memory management to trade broker stability under load and performance

  • The connection factory* properties to trade client-process size and reliability for performance

*A connection factory encapsulates a set of connection configuration parameters that the administrator has defined.

Deployment

At deployment, the administrator can choose the hardware used for the broker based on current system performance. Metrics information can also be obtained and analyzed to find system bottlenecks.

About the Author

Linda Schneider has been at Sun for more than seven years. For the past four years, she has worked as an engineer on the message-server component of Sun ONE Message Queue software, the broker.