43.3. Other Tunings

Use Asynchronous Send Acknowledgments. To send durable messages non transactionally and a guarantee is required that they have reached the server by the time the call to send() returns, do not set durable messages to be sent blocking, rather use asynchronous send acknowledgments to get the acknowledgments of send back in a separate stream. Refer to Chapter 18, Guarantees of sends and commits for more information on this.

Use pre-acknowledge mode. With pre-acknowledge mode, messages are acknowledged before being sent to the client. This reduces the amount of acknowledgment traffic being transmitted. For more information on this, refer to Chapter 27, Pre-Acknowledge Mode.

Disable persistence. If message persistence is not required, turn it off altogether by setting persistence-enabled to false in <JBOSS_HOME>/jboss-as/server/<PROFILE>/deploy/hornetq/hornetq-configuration.xml.

Sync transactions lazily. Setting journal-sync-transactional to false in hornetq-configuration.xml gives better transactional persistent performance at the expense of some possibility of loss of transactions on failure. Refer to Chapter 18, Guarantees of sends and commits for more information.

Sync non transactional lazily. Setting journal-sync-non-transactional to false in hornetq-configuration.xml can provide better non-transactional persistent performance at the expense of some possibility of loss of durable messages on failure. Refer to Chapter 18, Guarantees of sends and commits for more information.

Send messages non blocking. Setting block-on-durable-send and block-on-non-durable-send to false in JBOSS_DIST/jboss-as/server/<PROFILE>/deploy/hornetq/hornetq-jms.xml (if using JMS and JNDI) or directly on the ClientSessionFactory. It is therefore not required to wait an entire network round trip for every message sent. Refer to Chapter 18, Guarantees of sends and commits for more information.

For very fast consumers, increase consumer-window-size. This effectively disables consumer flow control.

Socket NIO vs Socket Old IO. By default HornetQ uses old (blocking) on the server and the client side (Refer to Chapter 14, Configuring the Transport for more information). NIO is much more scalable but can give some latency hit compared to old blocking IO. To be able to service many thousands of connections on the server, then ensure the use of NIO on the server. However, for fewer connections on the server, retaining the old IO for the server acceptors may gain a small performance advantage.

Use the core API not JMS. Using the JMS API will have slightly lower performance than using the core API, since all JMS operations need to be translated into core operations before the server can handle them. If 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 transmitted, so if you re-use SimpleString instances between calls, some unnecessary copying can be avoided.