src/components/artemis/documentation/latest/perf-tuning.html - activemq-website - Git at Google

 <!DOCTYPE html>
 <html lang="en">
 <head>
 <meta charset="UTF-8">
 <meta http-equiv="X-UA-Compatible" content="IE=edge">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <meta name="generator" content="Asciidoctor 2.0.18">
 <link rel="icon" type="image/png" href="images/favicon.png">
 <title>Performance Tuning</title>
 <link rel="stylesheet" href="css/asciidoctor.css">
 <link rel="stylesheet" href="css/font-awesome.css">
 <link rel="stylesheet" href="css/rouge-github.css">
 </head>
 <body class="book toc2 toc-left">
 <div id="header">
 <h1>Performance Tuning</h1>
 <div id="toc" class="toc2">
 <div id="toctitle"><a href="index.html">User Manual for 2.32.0</a></div>
 <ul class="sectlevel1">
 <li><a href="#tuning-persistence">1. Tuning persistence</a></li>
 <li><a href="#tuning-jms">2. Tuning JMS</a></li>
 <li><a href="#other-tunings">3. Other Tunings</a></li>
 <li><a href="#tuning-transport-settings">4. Tuning Transport Settings</a></li>
 <li><a href="#tuning-the-vm">5. Tuning the VM</a></li>
 <li><a href="#avoiding-anti-patterns">6. Avoiding Anti-Patterns</a></li>
 <li><a href="#troubleshooting">7. Troubleshooting</a>
 <ul class="sectlevel2">
 <li><a href="#udp-not-working">7.1. UDP not working</a></li>
 </ul>
 </li>
 </ul>
 </div>
 </div>
 <div id="content">
 <div id="preamble">
 <div class="sectionbody">
 <div class="paragraph">
 <p>In this chapter we&#8217;ll discuss how to tune Apache ActiveMQ Artemis for optimum performance.</p>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="tuning-persistence"><a class="anchor" href="#tuning-persistence"></a><a class="link" href="#tuning-persistence">1. Tuning persistence</a></h2>
 <div class="sectionbody">
 <div class="ulist">
 <ul>
 <li>
 <p>To get the best performance from Apache ActiveMQ Artemis whilst using persistent messages it is recommended that the file store is used.
 Apache ActiveMQ Artemis also supports JDBC persistence, but there is a performance cost when persisting to a database vs local disk.</p>
 </li>
 <li>
 <p>Put the message journal on its own physical volume.
 If the disk is shared with other processes e.g. transaction co-ordinator, database or other journals which are also reading and writing from it, then this may greatly reduce performance since the disk head may be skipping all over the place between the different files.
 One of the advantages of an append only journal is that disk head movement is minimised - this advantage is destroyed if the disk is shared.
 If you&#8217;re using paging or large messages make sure they&#8217;re ideally put on separate volumes too.</p>
 </li>
 <li>
 <p>Minimum number of journal files.
 Set <code>journal-min-files</code> to a number of files that would fit your average sustainable rate.
 This number represents the lower threshold of the journal file pool.</p>
 </li>
 <li>
 <p>To set the upper threshold of the journal file pool.
 (<code>journal-min-files</code> being the lower threshold).
 Set <code>journal-pool-files</code> to a number that represents something near your maximum expected load.
 The journal will spill over the pool should it need to, but will shrink back to the upper threshold, when possible.
 This allows reuse of files, without taking up more disk space than required.
 If you see new files being created on the journal data directory too often, i.e. lots of data is being persisted, you need to increase the journal-pool-size, this way the journal would reuse more files instead of creating new data files, increasing performance</p>
 </li>
 <li>
 <p>Journal file size.
 The journal file size should be aligned to the capacity of a cylinder on the disk.
 The default value 10MiB should be enough on most systems.</p>
 </li>
 <li>
 <p>Use <code>ASYNCIO</code> journal.
 If using Linux, try to keep your journal type as <code>ASYNCIO</code>.
 <code>ASYNCIO</code> will scale better than Java NIO.</p>
 </li>
 <li>
 <p>Tune <code>journal-buffer-timeout</code>.
 The timeout can be increased to increase throughput at the expense of latency.</p>
 </li>
 <li>
 <p>If you&#8217;re running <code>ASYNCIO</code> you might be able to get some better performance by increasing <code>journal-max-io</code>.
 DO NOT change this parameter if you are running NIO.</p>
 </li>
 <li>
 <p>If you are 100% sure you don&#8217;t need power failure durability guarantees, disable <code>journal-data-sync</code> and use <code>NIO</code> or <code>MAPPED</code> journal: you&#8217;ll benefit a huge performance boost on writes with process failure durability guarantees.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="tuning-jms"><a class="anchor" href="#tuning-jms"></a><a class="link" href="#tuning-jms">2. Tuning JMS</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>There are a few areas where some tweaks can be done if you are using the JMS API</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Disable message id.
 Use the <code>setDisableMessageID()</code> method on the <code>MessageProducer</code> class to disable message ids if you don&#8217;t need them.
 This decreases the size of the message and also avoids the overhead of creating a unique ID.</p>
 </li>
 <li>
 <p>Disable message timestamp.
 Use the <code>setDisableMessageTimeStamp()</code> method on the <code>MessageProducer</code> class to disable message timestamps if you don&#8217;t need them.</p>
 </li>
 <li>
 <p>Avoid <code>ObjectMessage</code>.
 <code>ObjectMessage</code> is convenient but it comes at a cost.
 The body of a <code>ObjectMessage</code> uses Java serialization to serialize it to bytes.
 The Java serialized form of even small objects is very verbose so takes up a lot of space on the wire, also Java serialization is slow compared to custom marshalling techniques.
 Only use <code>ObjectMessage</code> if you really can&#8217;t use one of the other message types, i.e. if you really don&#8217;t know the type of the payload until run-time.</p>
 </li>
 <li>
 <p>Avoid <code>AUTO_ACKNOWLEDGE</code>.
 <code>AUTO_ACKNOWLEDGE</code> mode requires an acknowledgement to be sent from the server for each message received on the client, this means more traffic on the network.
 If you can, use <code>DUPS_OK_ACKNOWLEDGE</code> or use <code>CLIENT_ACKNOWLEDGE</code> or a transacted session and batch up many acknowledgements with one acknowledge/commit.</p>
 </li>
 <li>
 <p>Avoid durable messages.
 By default JMS messages are durable.
 If you don&#8217;t really need durable messages then set them to be non-durable.
 Durable messages incur a lot more overhead in persisting them to storage.</p>
 </li>
 <li>
 <p>Batch many sends or acknowledgements in a single transaction.
 Apache ActiveMQ Artemis will only require a network round trip on the commit, not on every send or acknowledgement.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="other-tunings"><a class="anchor" href="#other-tunings"></a><a class="link" href="#other-tunings">3. Other Tunings</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>There are various other places in Apache ActiveMQ Artemis where we can perform some tuning:</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>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&#8217;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 <a href="send-guarantees.html#guarantees-of-sends-and-commits">Guarantees of sends and commits</a> for more information on this.</p>
 </li>
 <li>
 <p>Use pre-acknowledge mode.
 With pre-acknowledge mode, messages are acknowledged <code>before</code> they are sent to the client.
 This reduces the amount of acknowledgement traffic on the wire.
 For more information on this, see <a href="pre-acknowledge.html#extra-acknowledge-modes">Extra Acknowledge Modes</a>.</p>
 </li>
 <li>
 <p>Disable security.
 You may get a small performance boost by disabling security by setting the <code>security-enabled</code> parameter to <code>false</code> in <code>broker.xml</code>.</p>
 </li>
 <li>
 <p>Disable persistence.
 If you don&#8217;t need message persistence, turn it off altogether by setting <code>persistence-enabled</code> to false in <code>broker.xml</code>.</p>
 </li>
 <li>
 <p>Sync transactions lazily.
 Setting <code>journal-sync-transactional</code> to <code>false</code> in <code>broker.xml</code> can give you better transactional persistent performance at the expense of some possibility of loss of transactions on failure.
 See <a href="send-guarantees.html#guarantees-of-sends-and-commits">Guarantees of sends and commits</a> for more information.</p>
 </li>
 <li>
 <p>Sync non transactional lazily.
 Setting <code>journal-sync-non-transactional</code> to <code>false</code> in <code>broker.xml</code> can give you better non-transactional persistent performance at the expense of some possibility of loss of durable messages on failure.
 See  <a href="send-guarantees.html#guarantees-of-sends-and-commits">Guarantees of sends and commits</a> for more information.</p>
 </li>
 <li>
 <p>Send messages non blocking.
 Setting <code>block-on-durable-send</code> and <code>block-on-non-durable-send</code> to <code>false</code> in the jms config (if you&#8217;re using JMS and JNDI) or directly on the ServerLocator.
 This means you don&#8217;t have to wait a whole network round trip for every message sent.
 See  <a href="send-guarantees.html#guarantees-of-sends-and-commits">Guarantees of sends and commits</a> for more information.</p>
 </li>
 <li>
 <p>If you have very fast consumers, you can increase consumer-window-size.
 This effectively disables consumer flow control.</p>
 </li>
 <li>
 <p>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 <code>SimpleString</code> as much as possible.
 <code>SimpleString</code>, unlike java.lang.String does not require copying before it is written to the wire, so if you re-use <code>SimpleString</code> instances between calls then you can avoid some unnecessary copying.</p>
 </li>
 <li>
 <p>If using frameworks like Spring, configure destinations permanently broker side and enable <code>cacheDestinations</code> on the client side.
 See the <a href="using-jms.html#setting-the-destination-cache">Setting The Destination Cache</a> for more information on this.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="tuning-transport-settings"><a class="anchor" href="#tuning-transport-settings"></a><a class="link" href="#tuning-transport-settings">4. Tuning Transport Settings</a></h2>
 <div class="sectionbody">
 <div class="ulist">
 <ul>
 <li>
 <p>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 <a href="configuring-transports.html#configuring-the-transport">Configuring the Transport</a> for more information on this.</p>
 <div class="admonitionblock note">
 <table>
 <tr>
 <td class="icon">
 <i class="fa icon-note" title="Note"></i>
 </td>
 <td class="content">
 <div class="paragraph">
 <p>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!</p>
 </div>
 </td>
 </tr>
 </table>
 </div>
 </li>
 <li>
 <p>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.</p>
 <div class="paragraph">
 <p>This varies from operating system to operating system.
 On Linux systems you can increase the number of allowable open file handles in the file <code>/etc/security/limits.conf</code> e.g. add the lines</p>
 </div>
 <div class="listingblock">
 <div class="content">
 <pre class="nowrap">serveruser   soft  nofile  20000
 serveruser   hard  nofile  20000</pre>
 </div>
 </div>
 <div class="paragraph">
 <p>This would allow up to 20000 file handles to be open by the user <code>serveruser</code>.</p>
 </div>
 </li>
 <li>
 <p>Use <code>batch-delay</code> and set <code>direct-deliver</code> to false for the best throughput for very small messages.
 Apache ActiveMQ Artemis comes with a preconfigured connector/acceptor pair (<code>netty-throughput</code>) in <code>broker.xml</code> and JMS connection factory (<code>ThroughputConnectionFactory</code>) in <code>activemq-jms.xml</code>which can be used to give the very best throughput, especially for small messages.
 See the <a href="configuring-transports.html#configuring-the-transport">Configuring the Transport</a> for more information on this.</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="tuning-the-vm"><a class="anchor" href="#tuning-the-vm"></a><a class="link" href="#tuning-the-vm">5. Tuning the VM</a></h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>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&#8217;t apply to JDKs from other providers (e.g. IBM or JRockit)</p>
 </div>
 <div class="ulist">
 <ul>
 <li>
 <p>Memory settings.
 Give as much memory as you can to the server.
 Apache ActiveMQ Artemis can run in low memory by using paging (described in <a href="paging.html#paging">Paging</a>) but if it can run with all queues in RAM this will improve performance.
 The amount of memory you require will depend on the size and number of your queues and the size and number of your messages.
 Use the JVM arguments <code>-Xms</code> and <code>-Xmx</code> to set server available RAM.
 We recommend setting them to the same high value.</p>
 <div class="paragraph">
 <p>When under periods of high load, it is likely that Artemis will be generating and destroying lots of objects.
 This can result in a build up of stale objects.
 To reduce the chance of running out of memory and causing a full GC (which may introduce pauses and unintentional behaviour), it is recommended that the max heap size (<code>-Xmx</code>) for the JVM is set at least to 5 x the <code>global-max-size</code> of the broker.
 As an example, in a situation where the broker is under high load and running with a <code>global-max-size</code> of 1GB, it is recommended the max heap size is set to 5GB.</p>
 </div>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="avoiding-anti-patterns"><a class="anchor" href="#avoiding-anti-patterns"></a><a class="link" href="#avoiding-anti-patterns">6. Avoiding Anti-Patterns</a></h2>
 <div class="sectionbody">
 <div class="ulist">
 <ul>
 <li>
 <p>Re-use connections / sessions / consumers / producers.
 Probably the most common messaging anti-pattern we see is users who create a new connection/session/producer for every message they send or every message they consume.
 This is a poor use of resources.
 These objects take time to create and may involve several network round trips.
 Always re-use them.</p>
 <div class="admonitionblock note">
 <table>
 <tr>
 <td class="icon">
 <i class="fa icon-note" title="Note"></i>
 </td>
 <td class="content">
 <div class="paragraph">
 <p>Spring&#8217;s <code>JmsTemplate</code> is known to use this anti-pattern.
 It can only safely be used with a connection pool (e.g. in a Java EE application server using JCA), and even then it should only be used for sending messages.
 It cannot be safely be used for synchronously consuming messages, even with a connection pool.
 If you need a connection pool take a look at  <a href="https://github.com/messaginghub/pooled-jms">this</a> which was forked from the ActiveMQ code-base into its own project with full support for JMS 2.</p>
 </div>
 </td>
 </tr>
 </table>
 </div>
 </li>
 <li>
 <p>Avoid fat messages.
 Verbose formats such as XML take up a lot of space on the wire and performance will suffer as result.
 Avoid XML in message bodies if you can.</p>
 </li>
 <li>
 <p>Don&#8217;t 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 then send back a response to the address specified in the reply-to.
 A common mistake made with this pattern is to create a new temporary queue on each message sent.
 This will drastically reduce performance.
 Instead the temporary queue should be re-used for many requests.</p>
 </li>
 <li>
 <p>Don&#8217;t use Message-Driven Beans for the sake of it.
 As soon as you start using MDBs you are greatly increasing the codepath for each message received compared to a straightforward message consumer, since a lot of extra application server code is executed.
 Ask yourself do you really need MDBs?
 Can you accomplish the same task using just a normal message consumer?</p>
 </li>
 </ul>
 </div>
 </div>
 </div>
 <div class="sect1">
 <h2 id="troubleshooting"><a class="anchor" href="#troubleshooting"></a><a class="link" href="#troubleshooting">7. Troubleshooting</a></h2>
 <div class="sectionbody">
 <div class="sect2">
 <h3 id="udp-not-working"><a class="anchor" href="#udp-not-working"></a><a class="link" href="#udp-not-working">7.1. UDP not working</a></h3>
 <div class="paragraph">
 <p>In certain situations UDP used on discovery may not work.
 Typical situations are:</p>
 </div>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
 <p>The nodes are behind a firewall.
 If your nodes are on different machines then it is possible that the firewall is blocking the multicasts.
 you can test this by disabling the firewall for each node or adding the appropriate rules.</p>
 </li>
 <li>
 <p>You are using a home network or are behind a gateway.
 Typically home networks will redirect any UDP traffic to the Internet Service Provider which is then either dropped by the ISP or just lost.
 To fix this you will need to add a route to the firewall/gateway that will redirect any multicast traffic back on to the local network instead.</p>
 </li>
 <li>
 <p>All the nodes are in one machine.
 If this is the case then it is a similar problem to point 2 and the same solution should fix it.
 Alternatively you could add a multicast route to the loopback interface.
 On linux the command would be:</p>
 <div class="listingblock">
 <div class="content">
 <pre class="rouge highlight nowrap"><code data-lang="sh"><span class="c"># you should run this as root</span>
 route add <span class="nt">-net</span> 224.0.0.0 netmask 240.0.0.0 dev lo</code></pre>
 </div>
 </div>
 <div class="paragraph">
 <p>This will redirect any traffic directed to the 224.0.0.0 to the loopback interface.
 This will also work if you have no network at all.
 On Mac OS X, the command is slightly different:</p>
 </div>
 <div class="listingblock">
 <div class="content">
 <pre class="rouge highlight nowrap"><code data-lang="sh"><span class="nb">sudo </span>route add 224.0.0.0 127.0.0.1 <span class="nt">-netmask</span> 240.0.0.0</code></pre>
 </div>
 </div>
 </li>
 </ol>
 </div>
 </div>
 </div>
 </div>
 </div>
 </body>
 </html>
	<!DOCTYPE html>
	<html lang="en">
	<head>
	<meta charset="UTF-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<meta name="generator" content="Asciidoctor 2.0.18">
	<link rel="icon" type="image/png" href="images/favicon.png">
	<title>Performance Tuning</title>
	<link rel="stylesheet" href="css/asciidoctor.css">
	<link rel="stylesheet" href="css/font-awesome.css">
	<link rel="stylesheet" href="css/rouge-github.css">
	</head>
	<body class="book toc2 toc-left">
	<div id="header">
	<h1>Performance Tuning</h1>
	<div id="toc" class="toc2">
	<div id="toctitle"><a href="index.html">User Manual for 2.32.0</a></div>
	<ul class="sectlevel1">
	<li><a href="#tuning-persistence">1. Tuning persistence</a></li>
	<li><a href="#tuning-jms">2. Tuning JMS</a></li>
	<li><a href="#other-tunings">3. Other Tunings</a></li>
	<li><a href="#tuning-transport-settings">4. Tuning Transport Settings</a></li>
	<li><a href="#tuning-the-vm">5. Tuning the VM</a></li>
	<li><a href="#avoiding-anti-patterns">6. Avoiding Anti-Patterns</a></li>
	<li><a href="#troubleshooting">7. Troubleshooting</a>
	<ul class="sectlevel2">
	<li><a href="#udp-not-working">7.1. UDP not working</a></li>
	</ul>
	</li>
	</ul>
	</div>
	</div>
	<div id="content">
	<div id="preamble">
	<div class="sectionbody">
	<div class="paragraph">
	<p>In this chapter we’ll discuss how to tune Apache ActiveMQ Artemis for optimum performance.</p>
	</div>
	</div>
	</div>
	<div class="sect1">
	<h2 id="tuning-persistence"><a class="anchor" href="#tuning-persistence"></a><a class="link" href="#tuning-persistence">1. Tuning persistence</a></h2>
	<div class="sectionbody">
	<div class="ulist">
	<ul>
	<li>
	<p>To get the best performance from Apache ActiveMQ Artemis whilst using persistent messages it is recommended that the file store is used.
	Apache ActiveMQ Artemis also supports JDBC persistence, but there is a performance cost when persisting to a database vs local disk.</p>
	</li>
	<li>
	<p>Put the message journal on its own physical volume.
	If the disk is shared with other processes e.g. transaction co-ordinator, database or other journals which are also reading and writing from it, then this may greatly reduce performance since the disk head may be skipping all over the place between the different files.
	One of the advantages of an append only journal is that disk head movement is minimised - this advantage is destroyed if the disk is shared.
	If you’re using paging or large messages make sure they’re ideally put on separate volumes too.</p>
	</li>
	<li>
	<p>Minimum number of journal files.
	Set <code>journal-min-files</code> to a number of files that would fit your average sustainable rate.
	This number represents the lower threshold of the journal file pool.</p>
	</li>
	<li>
	<p>To set the upper threshold of the journal file pool.
	(<code>journal-min-files</code> being the lower threshold).
	Set <code>journal-pool-files</code> to a number that represents something near your maximum expected load.
	The journal will spill over the pool should it need to, but will shrink back to the upper threshold, when possible.
	This allows reuse of files, without taking up more disk space than required.
	If you see new files being created on the journal data directory too often, i.e. lots of data is being persisted, you need to increase the journal-pool-size, this way the journal would reuse more files instead of creating new data files, increasing performance</p>
	</li>
	<li>
	<p>Journal file size.
	The journal file size should be aligned to the capacity of a cylinder on the disk.
	The default value 10MiB should be enough on most systems.</p>
	</li>
	<li>
	<p>Use <code>ASYNCIO</code> journal.
	If using Linux, try to keep your journal type as <code>ASYNCIO</code>.
	<code>ASYNCIO</code> will scale better than Java NIO.</p>
	</li>
	<li>
	<p>Tune <code>journal-buffer-timeout</code>.
	The timeout can be increased to increase throughput at the expense of latency.</p>
	</li>
	<li>
	<p>If you’re running <code>ASYNCIO</code> you might be able to get some better performance by increasing <code>journal-max-io</code>.
	DO NOT change this parameter if you are running NIO.</p>
	</li>
	<li>
	<p>If you are 100% sure you don’t need power failure durability guarantees, disable <code>journal-data-sync</code> and use <code>NIO</code> or <code>MAPPED</code> journal: you’ll benefit a huge performance boost on writes with process failure durability guarantees.</p>
	</li>
	</ul>
	</div>
	</div>
	</div>
	<div class="sect1">
	<h2 id="tuning-jms"><a class="anchor" href="#tuning-jms"></a><a class="link" href="#tuning-jms">2. Tuning JMS</a></h2>
	<div class="sectionbody">
	<div class="paragraph">
	<p>There are a few areas where some tweaks can be done if you are using the JMS API</p>
	</div>
	<div class="ulist">
	<ul>
	<li>
	<p>Disable message id.
	Use the <code>setDisableMessageID()</code> method on the <code>MessageProducer</code> class to disable message ids if you don’t need them.
	This decreases the size of the message and also avoids the overhead of creating a unique ID.</p>
	</li>
	<li>
	<p>Disable message timestamp.
	Use the <code>setDisableMessageTimeStamp()</code> method on the <code>MessageProducer</code> class to disable message timestamps if you don’t need them.</p>
	</li>
	<li>
	<p>Avoid <code>ObjectMessage</code>.
	<code>ObjectMessage</code> is convenient but it comes at a cost.
	The body of a <code>ObjectMessage</code> uses Java serialization to serialize it to bytes.
	The Java serialized form of even small objects is very verbose so takes up a lot of space on the wire, also Java serialization is slow compared to custom marshalling techniques.
	Only use <code>ObjectMessage</code> if you really can’t use one of the other message types, i.e. if you really don’t know the type of the payload until run-time.</p>
	</li>
	<li>
	<p>Avoid <code>AUTO_ACKNOWLEDGE</code>.
	<code>AUTO_ACKNOWLEDGE</code> mode requires an acknowledgement to be sent from the server for each message received on the client, this means more traffic on the network.
	If you can, use <code>DUPS_OK_ACKNOWLEDGE</code> or use <code>CLIENT_ACKNOWLEDGE</code> or a transacted session and batch up many acknowledgements with one acknowledge/commit.</p>
	</li>
	<li>
	<p>Avoid durable messages.
	By default JMS messages are durable.
	If you don’t really need durable messages then set them to be non-durable.
	Durable messages incur a lot more overhead in persisting them to storage.</p>
	</li>
	<li>
	<p>Batch many sends or acknowledgements in a single transaction.
	Apache ActiveMQ Artemis will only require a network round trip on the commit, not on every send or acknowledgement.</p>
	</li>
	</ul>
	</div>
	</div>
	</div>
	<div class="sect1">
	<h2 id="other-tunings"><a class="anchor" href="#other-tunings"></a><a class="link" href="#other-tunings">3. Other Tunings</a></h2>
	<div class="sectionbody">
	<div class="paragraph">
	<p>There are various other places in Apache ActiveMQ Artemis where we can perform some tuning:</p>
	</div>
	<div class="ulist">
	<ul>
	<li>
	<p>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 <a href="send-guarantees.html#guarantees-of-sends-and-commits">Guarantees of sends and commits</a> for more information on this.</p>
	</li>
	<li>
	<p>Use pre-acknowledge mode.
	With pre-acknowledge mode, messages are acknowledged <code>before</code> they are sent to the client.
	This reduces the amount of acknowledgement traffic on the wire.
	For more information on this, see <a href="pre-acknowledge.html#extra-acknowledge-modes">Extra Acknowledge Modes</a>.</p>
	</li>
	<li>
	<p>Disable security.
	You may get a small performance boost by disabling security by setting the <code>security-enabled</code> parameter to <code>false</code> in <code>broker.xml</code>.</p>
	</li>
	<li>
	<p>Disable persistence.
	If you don’t need message persistence, turn it off altogether by setting <code>persistence-enabled</code> to false in <code>broker.xml</code>.</p>
	</li>
	<li>
	<p>Sync transactions lazily.
	Setting <code>journal-sync-transactional</code> to <code>false</code> in <code>broker.xml</code> can give you better transactional persistent performance at the expense of some possibility of loss of transactions on failure.
	See <a href="send-guarantees.html#guarantees-of-sends-and-commits">Guarantees of sends and commits</a> for more information.</p>
	</li>
	<li>
	<p>Sync non transactional lazily.
	Setting <code>journal-sync-non-transactional</code> to <code>false</code> in <code>broker.xml</code> can give you better non-transactional persistent performance at the expense of some possibility of loss of durable messages on failure.
	See <a href="send-guarantees.html#guarantees-of-sends-and-commits">Guarantees of sends and commits</a> for more information.</p>
	</li>
	<li>
	<p>Send messages non blocking.
	Setting <code>block-on-durable-send</code> and <code>block-on-non-durable-send</code> to <code>false</code> in the jms config (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 <a href="send-guarantees.html#guarantees-of-sends-and-commits">Guarantees of sends and commits</a> for more information.</p>
	</li>
	<li>
	<p>If you have very fast consumers, you can increase consumer-window-size.
	This effectively disables consumer flow control.</p>
	</li>
	<li>
	<p>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 <code>SimpleString</code> as much as possible.
	<code>SimpleString</code>, unlike java.lang.String does not require copying before it is written to the wire, so if you re-use <code>SimpleString</code> instances between calls then you can avoid some unnecessary copying.</p>
	</li>
	<li>
	<p>If using frameworks like Spring, configure destinations permanently broker side and enable <code>cacheDestinations</code> on the client side.
	See the <a href="using-jms.html#setting-the-destination-cache">Setting The Destination Cache</a> for more information on this.</p>
	</li>
	</ul>
	</div>
	</div>
	</div>
	<div class="sect1">
	<h2 id="tuning-transport-settings"><a class="anchor" href="#tuning-transport-settings"></a><a class="link" href="#tuning-transport-settings">4. Tuning Transport Settings</a></h2>
	<div class="sectionbody">
	<div class="ulist">
	<ul>
	<li>
	<p>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 <a href="configuring-transports.html#configuring-the-transport">Configuring the Transport</a> for more information on this.</p>
	<div class="admonitionblock note">
	<table>
	<tr>
	<td class="icon">
	<i class="fa icon-note" title="Note"></i>
	</td>
	<td class="content">
	<div class="paragraph">
	<p>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!</p>
	</div>
	</td>
	</tr>
	</table>
	</div>
	</li>
	<li>
	<p>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.</p>
	<div class="paragraph">
	<p>This varies from operating system to operating system.
	On Linux systems you can increase the number of allowable open file handles in the file <code>/etc/security/limits.conf</code> e.g. add the lines</p>
	</div>
	<div class="listingblock">
	<div class="content">
	<pre class="nowrap">serveruser soft nofile 20000
	serveruser hard nofile 20000</pre>
	</div>
	</div>
	<div class="paragraph">
	<p>This would allow up to 20000 file handles to be open by the user <code>serveruser</code>.</p>
	</div>
	</li>
	<li>
	<p>Use <code>batch-delay</code> and set <code>direct-deliver</code> to false for the best throughput for very small messages.
	Apache ActiveMQ Artemis comes with a preconfigured connector/acceptor pair (<code>netty-throughput</code>) in <code>broker.xml</code> and JMS connection factory (<code>ThroughputConnectionFactory</code>) in <code>activemq-jms.xml</code>which can be used to give the very best throughput, especially for small messages.
	See the <a href="configuring-transports.html#configuring-the-transport">Configuring the Transport</a> for more information on this.</p>
	</li>
	</ul>
	</div>
	</div>
	</div>
	<div class="sect1">
	<h2 id="tuning-the-vm"><a class="anchor" href="#tuning-the-vm"></a><a class="link" href="#tuning-the-vm">5. Tuning the VM</a></h2>
	<div class="sectionbody">
	<div class="paragraph">
	<p>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)</p>
	</div>
	<div class="ulist">
	<ul>
	<li>
	<p>Memory settings.
	Give as much memory as you can to the server.
	Apache ActiveMQ Artemis can run in low memory by using paging (described in <a href="paging.html#paging">Paging</a>) but if it can run with all queues in RAM this will improve performance.
	The amount of memory you require will depend on the size and number of your queues and the size and number of your messages.
	Use the JVM arguments <code>-Xms</code> and <code>-Xmx</code> to set server available RAM.
	We recommend setting them to the same high value.</p>
	<div class="paragraph">
	<p>When under periods of high load, it is likely that Artemis will be generating and destroying lots of objects.
	This can result in a build up of stale objects.
	To reduce the chance of running out of memory and causing a full GC (which may introduce pauses and unintentional behaviour), it is recommended that the max heap size (<code>-Xmx</code>) for the JVM is set at least to 5 x the <code>global-max-size</code> of the broker.
	As an example, in a situation where the broker is under high load and running with a <code>global-max-size</code> of 1GB, it is recommended the max heap size is set to 5GB.</p>
	</div>
	</li>
	</ul>
	</div>
	</div>
	</div>
	<div class="sect1">
	<h2 id="avoiding-anti-patterns"><a class="anchor" href="#avoiding-anti-patterns"></a><a class="link" href="#avoiding-anti-patterns">6. Avoiding Anti-Patterns</a></h2>
	<div class="sectionbody">
	<div class="ulist">
	<ul>
	<li>
	<p>Re-use connections / sessions / consumers / producers.
	Probably the most common messaging anti-pattern we see is users who create a new connection/session/producer for every message they send or every message they consume.
	This is a poor use of resources.
	These objects take time to create and may involve several network round trips.
	Always re-use them.</p>
	<div class="admonitionblock note">
	<table>
	<tr>
	<td class="icon">
	<i class="fa icon-note" title="Note"></i>
	</td>
	<td class="content">
	<div class="paragraph">
	<p>Spring’s <code>JmsTemplate</code> is known to use this anti-pattern.
	It can only safely be used with a connection pool (e.g. in a Java EE application server using JCA), and even then it should only be used for sending messages.
	It cannot be safely be used for synchronously consuming messages, even with a connection pool.
	If you need a connection pool take a look at <a href="https://github.com/messaginghub/pooled-jms">this</a> which was forked from the ActiveMQ code-base into its own project with full support for JMS 2.</p>
	</div>
	</td>
	</tr>
	</table>
	</div>
	</li>
	<li>
	<p>Avoid fat messages.
	Verbose formats such as XML take up a lot of space on the wire and performance will suffer as result.
	Avoid XML in message bodies if you can.</p>
	</li>
	<li>
	<p>Don’t 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 then send back a response to the address specified in the reply-to.
	A common mistake made with this pattern is to create a new temporary queue on each message sent.
	This will drastically reduce performance.
	Instead the temporary queue should be re-used for many requests.</p>
	</li>
	<li>
	<p>Don’t use Message-Driven Beans for the sake of it.
	As soon as you start using MDBs you are greatly increasing the codepath for each message received compared to a straightforward message consumer, since a lot of extra application server code is executed.
	Ask yourself do you really need MDBs?
	Can you accomplish the same task using just a normal message consumer?</p>
	</li>
	</ul>
	</div>
	</div>
	</div>
	<div class="sect1">
	<h2 id="troubleshooting"><a class="anchor" href="#troubleshooting"></a><a class="link" href="#troubleshooting">7. Troubleshooting</a></h2>
	<div class="sectionbody">
	<div class="sect2">
	<h3 id="udp-not-working"><a class="anchor" href="#udp-not-working"></a><a class="link" href="#udp-not-working">7.1. UDP not working</a></h3>
	<div class="paragraph">
	<p>In certain situations UDP used on discovery may not work.
	Typical situations are:</p>
	</div>
	<div class="olist arabic">
	<ol class="arabic">
	<li>
	<p>The nodes are behind a firewall.
	If your nodes are on different machines then it is possible that the firewall is blocking the multicasts.
	you can test this by disabling the firewall for each node or adding the appropriate rules.</p>
	</li>
	<li>
	<p>You are using a home network or are behind a gateway.
	Typically home networks will redirect any UDP traffic to the Internet Service Provider which is then either dropped by the ISP or just lost.
	To fix this you will need to add a route to the firewall/gateway that will redirect any multicast traffic back on to the local network instead.</p>
	</li>
	<li>
	<p>All the nodes are in one machine.
	If this is the case then it is a similar problem to point 2 and the same solution should fix it.
	Alternatively you could add a multicast route to the loopback interface.
	On linux the command would be:</p>
	<div class="listingblock">
	<div class="content">
	<pre class="rouge highlight nowrap"><code data-lang="sh"><span class="c"># you should run this as root</span>
	route add <span class="nt">-net</span> 224.0.0.0 netmask 240.0.0.0 dev lo</code></pre>
	</div>
	</div>
	<div class="paragraph">
	<p>This will redirect any traffic directed to the 224.0.0.0 to the loopback interface.
	This will also work if you have no network at all.
	On Mac OS X, the command is slightly different:</p>
	</div>
	<div class="listingblock">
	<div class="content">
	<pre class="rouge highlight nowrap"><code data-lang="sh"><span class="nb">sudo </span>route add 224.0.0.0 127.0.0.1 <span class="nt">-netmask</span> 240.0.0.0</code></pre>
	</div>
	</div>
	</li>
	</ol>
	</div>
	</div>
	</div>
	</div>
	</div>
	</body>
	</html>