JBoss.orgCommunity Documentation

Chapter 48. Performance Tuning

48.1. Tuning persistence
48.2. Tuning JMS
48.3. Other Tunings
48.4. Tuning Transport Settings
48.5. Tuning the VM
48.6. Avoiding Anti-Patterns

In this chapter we'll discuss how to tune HornetQ for optimum performance.

There are a few areas where some tweaks can be done if you are using the JMS API

There are various other places in HornetQ where we can perform some tuning:

  • Use Asynchronous Send Acknowledgements. If you need to send durable messages non transactionally and you need a guarantee that they have reached the server by the time the call to send() returns, don't set durable messages to be sent blocking, instead use asynchronous send acknowledgements to get your acknowledgements of send back in a separate stream, see Chapter 20, Guarantees of sends and commits for more information on this.

  • Use pre-acknowledge mode. With pre-acknowledge mode, messages are acknowledged before they are sent to the client. This reduces the amount of acknowledgement traffic on the wire. For more information on this, see Chapter 29, Extra Acknowledge Modes.

  • Disable security. You may get a small performance boost by disabling security by setting the security-enabled parameter to false in hornetq-configuration.xml.

  • Disable persistence. If you don't need message persistence, turn it off altogether by setting persistence-enabled to false in hornetq-configuration.xml.

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

  • Sync non transactional lazily. Setting journal-sync-non-transactional to false in hornetq-configuration.xml can give you better non-transactional persistent performance at the expense of some possibility of loss of durable messages on failure. See Chapter 20, 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 hornetq-jms.xml (if you're using JMS and JNDI) or directly on the ServerLocator. This means you don't have to wait a whole network round trip for every message sent. See Chapter 20, Guarantees of sends and commits for more information.

  • If you have very fast consumers, you can 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 (see the chapter on configuring transports for more information Chapter 16, Configuring the Transport). NIO is much more scalable but can give you some latency hit compared to old blocking IO. If you need to be able to service many thousands of connections on the server, then you should make sure you're using NIO on the server. However, if don't expect many thousands of connections on the server you can keep the server acceptors using old IO, and might get a small performance advantage.

  • Use the core API not JMS. Using the JMS API you 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 written to the wire, so if you re-use SimpleString instances between calls then you can avoid some unnecessary copying.

  • TCP buffer sizes. If you have a fast network and fast machines you may get a performance boost by increasing the TCP send and receive buffer sizes. See the Chapter 16, Configuring the Transport for more information on this.

    Note

    Note that some operating systems like later versions of Linux include TCP auto-tuning and setting TCP buffer sizes manually can prevent auto-tune from working and actually give you worse performance!

  • Increase limit on file handles on the server. If you expect a lot of concurrent connections on your servers, or if clients are rapidly opening and closing connections, you should make sure the user running the server has permission to create sufficient file handles.

    This varies from operating system to operating system. On Linux systems you can increase the number of allowable open file handles in the file /etc/security/limits.conf e.g. add the lines

    serveruser     soft    nofile  20000
    serveruser     hard    nofile  20000

    This would allow up to 20000 file handles to be open by the user serveruser.

  • Use batch-delay and set direct-deliver to false for the best throughput for very small messages. HornetQ comes with a preconfigured connector/acceptor pair (netty-throughput) in hornetq-configuration.xml and JMS connection factory (ThroughputConnectionFactory) in hornetq-jms.xmlwhich can be used to give the very best throughput, especially for small messages. See the Chapter 16, Configuring the Transport for more information on this.

We highly recommend you use the latest Java JVM for the best performance. We test internally using the Sun JVM, so some of these tunings won't apply to JDKs from other providers (e.g. IBM or JRockit)