Factors Affecting Performance

Application design decisions can have a significant effect on
overall messaging performance. The most important factors affecting performance
are those that impact the reliability of message delivery; among these are
the following:

The sections that follow describe the impact of each of these factors
on messaging performance. As a general rule, there is a trade-off between
performance and reliability: factors that increase reliability tend to decrease
performance.

Table 3–4 shows how application
design factors affect messaging performance. The table shows two scenarios—a
high-reliability, low-performance scenario and a high-performance, low-reliability
scenario—and the choice of application design factors that characterizes
each. Between these extremes, there are many choices and trade-offs that affect
both reliability and performance.

Table 3–4 Comparison of High
Reliability and High Performance Scenarios

Application DesignFactor

High Reliability, Low Performance

High Performance, Low Reliability

Delivery mode

Persistent messages

Nonpersistent messages

Use of transactions

Transacted sessions

No transactions

Acknowledgment mode

AUTO_ACKNOWLEDGE

CLIENT_ACKNOWLEDGE

DUPS_OK_ACKNOWLEDGE

NO_ACKNOWLEDGE

Durable/nondurable subscriptions

Durable subscriptions

Nondurable subscriptions

Use of selectors

Message filtering

No message filtering

Message size

Small messages

Large messages

Message body type

Complex body types

Simple body types

Delivery Mode (Persistent/Nonpersistent)

Persistent messages guarantee message delivery in case of broker failure.
The broker stores these message in a persistent store until all intended consumers
acknowledge that they have consumed the message.

Broker processing of persistent messages is slower than for nonpersistent
messages for the following reasons:

A broker must reliably store a persistent message so that
it will not be lost should the broker fail.

The broker must confirm receipt of each persistent message
it receives. Delivery to the broker is guaranteed once the method producing
the message returns without an exception.

Depending on the client acknowledgment mode, the broker might
need to confirm a consuming client’s acknowledgment of a persistent
message.

For both queues and topics with durable subscribers, performance was
approximately 40% faster for non-persistent messages. We obtained these results
using 10K-size messages and AUTO_ACKNOWLEDGE mode.

Use of Transactions

A transaction guarantees that all messages produced in a transacted
session and all messages consumed in a transacted session will be either processed
or not processed (rolled back) as a unit. Message Queue supports both local
and distributed transactions.

A message produced or acknowledged in a transacted session is slower
than in a non-transacted session for the following reasons:

Additional information must be stored with each produced message.

In some situations, messages in a transaction are stored when
normally they would not be. For example, a persistent message delivered to
a topic destination with no subscriptions would normally be deleted, however,
at the time the transaction is begun, information about subscriptions is not
available.

Information on the consumption and acknowledgment of messages
within a transaction must be stored and processed when the transaction is
committed.

Acknowledgment Mode

Other than using transactions, you can ensure reliable delivery by having
the client acknowledge receiving a message. If a session is closed without
the client acknowledging the message or if the message broker fails before
the acknowledgment is processed, the broker redelivers that message, setting
a JMSRedelivered flag.

For a non-transacted session, the client can choose one of three acknowledgment
modes, each of which has its own performance characteristics:

AUTO_ACKNOWLEDGE. The system automatically
acknowledges a message once the consumer has processed it. This mode guarantees
at most one redelivered message after a provider failure.

CLIENT_ACKNOWLEDGE. The application controls
the point at which messages are acknowledged. All messages processed in that
session since the previous acknowledgment are acknowledged. If the broker
fails while processing a set of acknowledgments, one or more messages in that
group might be redelivered.

(Using CLIENT_ACKNOWLEDGE mode
is similar to using transactions, except there is no guarantee that all acknowledgments
will be processed together if a provider fails during processing.)

DUPS_OK_ACKNOWLEDGE. This mode instructs
the system to acknowledge messages in a lazy manner. Multiple messages can
be redelivered after a provider failure.

NO_ACKNOWLEDGE In this mode, the broker
considers a message acknowledged as soon as it has been written to the client.
The broker does not wait for an acknowledgment from the receiving client.
This mode is best used by typic subscribers who are not worried about reliability.

Performance is impacted by acknowledgment mode for the following reasons:

Extra control messages between broker and client are required
in AUTO_ACKNOWLEDGE and CLIENT_ACKNOWLEDGE modes.
The additional control messages add processing overhead and can interfere
with JMS payload messages, causing processing delays.

In AUTO_ACKNOWLEDGE and CLIENT_ACKNOWLEDGE modes, the client must wait until the broker confirms that it has
processed the client’s acknowledgment before the client can consume
more messages. (This broker confirmation guarantees that the broker will not
inadvertently redeliver these messages.)

The Message Queue persistent store must be updated with the
acknowledgment information for all persistent messages received by consumers,
thereby decreasing performance.

Durable vs. Nondurable Subscriptions

Subscribers to a topic destination have either durable and nondurable
subscriptions. Durable subscriptions provide increased reliability at the
cost of slower throughput for the following reasons:

The Message Queue message broker must persistently store the
list of messages assigned to each durable subscription so that should the
broker fail, the list is available after recovery.

Persistent messages for durable subscriptions are stored persistently,
so that should a broker fail, the messages can still be delivered after recovery,
when the corresponding consumer becomes active. By contrast, persistent messages
for nondurable subscriptions are not stored persistently (should a broker
fail, the corresponding consumer connection is lost and the message would
never be delivered).

We compared performance for durable and non-durable subscribers in two
cases: persistent and nonpersistent 10k-sized messages. Both cases use AUTO_ACKNOWLEDGE acknowledgment mode. We found a performance impact only in the
case of persistent messages, which slowed messages conveyed to durable subscribers
by about 30%.

Use of Selectors (Message Filtering)

Application developers can have the messaging provider sort messages
according to criteria specified in the message selector associated with a
consumer and deliver to that consumer only those messages whose property value
matches the message selector. For example, if an application creates a subscriber
to the topic WidgetOrders and specifies the expression NumberOfOrders >1000 for the message selector, messages with a NumberOfOrders property value of 1001 or more
are delivered to that subscriber.

Creating consumers with selectors lowers performance (as compared to
using multiple destinations) because additional processing is required to
handle each message. When a selector is used, it must be parsed so that it
can be matched against future messages. Additionally, the message properties
of each message must be retrieved and compared against the selector as each
message is routed. However, using selectors provides more flexibility in a
messaging application and may lower resource requirements at the expense of
speed.

Message Size

Message size affects performance because more data must be passed from
producing client to broker and from broker to consuming client, and because
for persistent messages a larger message must be stored.

However, by batching smaller messages into a single message, the routing
and processing of individual messages can be minimized, providing an overall
performance gain. In this case, information about the state of individual
messages is lost.

In our tests, which compared throughput in kilobytes per second for
1K, 10K, and 100K-sized messages to a queue destination using AUTO_ACKNOWLEDGE mode, we found that non-persistent messaging was about 50% faster
for 1K messages, about 20% faster for 10K messages, and about 5% faster for
100K messages. The size of the message affected performance significantly
for both persistent and non-persistent messages. 100k messages are about 10
times faster than 10K, and 10K messages are about 5 times faster than 1K.

Message Body Type

JMS supports five message body types, shown below roughly in the order
of complexity:

Bytes: Contains a set of
bytes in a format determined by the application

Text: Is a simple java.lang.String

Stream: Contains a stream
of Java primitive values

Map: Contains a set of
name-and-value pairs

Object: Contains a Java
serialized object

While, in general, the message type is dictated by the needs of an application,
the more complicated types (map and object) carry a performance cost —
the expense of serializing and deserializing the data. The performance cost
depends on how simple or how complicated the data is.