Chapter 7. Messaging subsystem tuning

Disable the message ID.

If you do not need message IDs, disable them by using the setDisableMessageID() method on the MessageProducer class. Setting the value to true eliminates the overhead of creating a unique ID and decreases the size of the message.

Disable the message timestamp.

If you do not need message timestamps, disable them by using the setDisableMessageTimeStamp() method on the MessageProducer class. Setting the value to true eliminates the overhead of creating the timestamp and decreases the size of the message.

Avoid using ObjectMessage.

ObjectMessage is used to send a message that contains a serialized object, meaning the body of the message, or payload, is sent over the wire as a stream of bytes. The Java serialized form of even small objects is quite large and takes up a lot of space on the wire. It is also slow when compared to custom marshalling techniques. Use ObjectMessage only if you cannot use one of the other message types, for example, if you do not know the type of the payload until runtime.

Avoid AUTO_ACKNOWLEDGE.

The choice of acknowledgement mode in a consumer impacts performance because of the additional overhead and traffic incurred by sending the acknowledgment message sent over the network. AUTO_ACKNOWLEDGE incurs this overhead because it requires an acknowledgement to be sent from the server for each message received on the client. If you can, use DUPS_OK_ACKNOWLEDGE, which acknowledges messages in a lazy manner, CLIENT_ACKNOWLEDGE, meaning the client code will call a method to acknowledge the message, or batch up many acknowledgements with one acknowledge or commit in a transacted session.

Avoid durable messages.

By default, Jakarta Messaging messages are durable. If you do not need durable messages, set them to be non-durable. Durable messages incur a lot of overhead because they are persisted to storage.

Use TRANSACTED_SESSION mode to send and receive messages in a single transaction.

By batching messages in a single transaction, the ActiveMQ Artemis server integrated in JBoss EAP requires only one network round trip on the commit, not on every send or receive.

Put the message journal on its own physical volume.

One of the advantages of an append-only journal is that disk head movement is minimized. This advantage is lost if the disk is shared. When multiple processes, such as a transaction coordinator, databases, and other journals, read and write from the same disk, performance is impacted because the disk head must skip around between different files. If you are using paging or large messages, make sure they are also put on separate volumes.

Tune the journal-min-files value.

Set the journal-min-files parameter to the number of files that fits your average sustainable rate. If you frequently see new files being created on the journal data directory, meaning a lot data is being persisted, you need to increase the minimal number of files. This allows the journal to reuse, rather than create, new data files.

Optimize the journal file size.

The journal file size must be aligned to the capacity of a cylinder on the disk. The default value of 10MB should be enough on most systems.

Use the AIO journal type.

For Linux operating systems, keep your journal type as AIO. AIO scales better than Java NIO.

Tune the journal-buffer-timeout value.

Increasing the journal-buffer-timeout value results in increased throughput at the expense of latency.

Tune the journal-max-io value.

If you are using AIO, you might be able improve performance by increasing the journal-max-io parameter value. Do not change this value if you are using NIO.

Use asynchronous send acknowledgements.

If you need to send non-transactional, durable messages and do not need a guarantee that they have reached the server by the time the call to send() returns, do not set them to be sent blocking. Instead use asynchronous send acknowledgements to get your send acknowledgements returned in a separate stream. However, in the case of a server crash, some messages might be lost.

Use pre-acknowledge mode.

With pre-acknowledge mode, messages are acknowledged before they are sent to the client. This reduces the amount of acknowledgment traffic on the wire. However, if that client crashes, messages will not be redelivered if the client reconnects.

Disable security.

There is a small performance boost when you disable security by setting the security-enabled attribute to false.

Disable persistence.

You can turn off message persistence altogether by setting persistence-enabled to false.

Sync transactions lazily.

Setting journal-sync-transactional to false provides better transactional persistent performance at the expense of some possibility of loss of transactions on failure.

Sync non-transactional lazily.

Setting journal-sync-non-transactional to false provides better non-transactional persistent performance at the expense of some possibility of loss of durable messages on failure.

Send messages non-blocking.

To avoid waiting for a network round trip for every message sent, set block-on-durable-send and block-on-non-durable-send to false if you are using Jakarta Messaging and JNDI, or set it directly on the ServerLocator by calling the setBlockOnDurableSend() and setBlockOnNonDurableSend() methods.

Optimize the consumer-window-size.

If you have very fast consumers, you can increase the consumer-window-size to effectively disable consumer flow control.

Use the core API instead of the Jakarta Messaging API.

Jakarta Messaging operations must be translated into core operations before the server can handle them, resulting in lower performance than when you use the core API. When using the core API, try to use methods that take SimpleString as much as possible. SimpleString, unlike java.lang.String, does not require copying before it is written to the wire, so if you reuse SimpleString instances between calls, you can avoid some unnecessary copying. Note that the core API is not portable to other brokers.

Reuse connections, sessions, consumers, and producers where possible.

The most common messaging anti-pattern is the creation of a new connection, session, and producer for every message sent or consumed. These objects take time to create and may involve several network round trips, so it is a poor use of resources. Always reuse them.

Avoid fat messages.

Verbose formats such as XML take up a lot of space on the wire and performance suffers as result. Avoid XML in message bodies if you can.

Do not create temporary queues for each request.

This common anti-pattern involves the temporary queue request-response pattern. With the temporary queue request-response pattern, a message is sent to a target, and a reply-to header is set with the address of a local temporary queue. When the recipient receives the message, they process it, and then send back a response to the address specified in the reply-to header. A common mistake made with this pattern is to create a new temporary queue on each message sent, which drastically reduces performance. Instead, the temporary queue should be reused for many requests.

Do not use message driven beans unless it is necessary.

Using MDBs to consume messages is slower than consuming messages using a simple Jakarta Messaging message consumer.