This topic has not yet been written. The content below is from the topic description.
46.3. Other Tunings 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, Pre-Acknowledge Mode. 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 ClientSessionFactory. 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.