activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r998478 - in /websites/production/activemq/content: cache/main.pageCache nio-transport-reference.html
Date Wed, 28 Sep 2016 12:22:26 GMT
Author: buildbot
Date: Wed Sep 28 12:22:26 2016
New Revision: 998478

Log:
Production update by buildbot for activemq

Modified:
    websites/production/activemq/content/cache/main.pageCache
    websites/production/activemq/content/nio-transport-reference.html

Modified: websites/production/activemq/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/activemq/content/nio-transport-reference.html
==============================================================================
--- websites/production/activemq/content/nio-transport-reference.html (original)
+++ websites/production/activemq/content/nio-transport-reference.html Wed Sep 28 12:22:26
2016
@@ -83,7 +83,7 @@
         <td valign="top" width="100%">
 <div class="wiki-content maincontent"><p>NIO Transport is very similar to the
regular <a shape="rect" href="tcp-transport-reference.html">TCP transport</a>.
The difference is that it is implemented using NIO API which can help with performance and
scalability.&#160;NIO is a server side transport option only. Trying to use it on the
client side will instantiate the regular TCP transport.</p><h4 id="NIOTransportReference-ConfigurationSyntax">Configuration
Syntax</h4><p><code><strong>nio://hostname:port?key=value</strong></code></p><p>Configuration
options are the same as for the <a shape="rect" href="tcp-transport-reference.html">TCP
transport</a>.</p><p>Note that the original NIO transport is a replacement
for the tcp transport that uses OpenWire protocol. Other network protocols, such AMQP, MQTT,
Stomp, etc also have their own NIO transport implementations. It configured usually, by adding
"+nio" suffix to the protocol prefix, like</p><div class="code panel pdl" style="border-width:
  1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">mqtt+nio://localhost:1883</pre>
-</div></div><p>All protocol specific configuration should be applicable
to the NIO version of the transport as well.</p><h3 id="NIOTransportReference-TuningNIOtransportthreadusage">Tuning
NIO transport thread usage</h3><p>One of the main advantages of using NIO instead
of the regular versions of the transport is that it can scale better and support larger number
of connections. The main limit in this scenario is the number of threads the system in using.
In blocking implementations of the transports, one thread is used per connection. In the NIO
implementation, there's a shared pool of threads that will take the load, so that number of
connections are not directly related to the number of threads used in the system.</p><p>You
can tune the number of threads used by the transport using the following system properties
(available since <strong>5.15.0</strong>)</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh">Property</
 th><th colspan="1" rowspan="1" class="confluenceTh">Default value</th><th
colspan="1" rowspan="1" class="confluenceTh">Description</th></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd">org.apache.activemq.transport.nio.SelectorManager.corePoolSize</td><td
colspan="1" rowspan="1" class="confluenceTd">10</td><td colspan="1" rowspan="1"
class="confluenceTd"><p>The number of threads to keep in the pool, even if they are
idle</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.activemq.transport.nio.SelectorManager.maximumPoolSize</td><td
colspan="1" rowspan="1" class="confluenceTd">1024</td><td colspan="1" rowspan="1"
class="confluenceTd"><p>The maximum number of threads to allow in the pool</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>org.apache.activemq.transport.nio.SelectorManager.workQueueCapacity</p></td><td
colspan="1" rowspan="1" class="confluenceTd">&#160;0</td><td colspan="1" rowspan="1"
class="confluenceTd">&#160;The ma
 x work queue depth before growing the pool</td></tr></tbody></table></div><p>If
you want to scale your broker to support thousands of connections to it, you need to first
find the limits of number of threads JVM process is allowed to create. Then you can set these
properties to some value below that (broker need more threads to operate normally). For more
information on thread usage by destinations and how to limit those, please take a look at
<a shape="rect" href="scaling-queues.html">Scaling Queues</a>&#160;or&#160;<a
shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/activemq/trunk/assembly/src/sample-conf/activemq-scalability.xml">this
configuration file</a>. For example you can add the following</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>All protocol specific configuration should be applicable
to the NIO version of the transport as well.</p><h3 id="NIOTransportReference-TuningNIOtransportthreadusage">Tuning
NIO transport thread usage</h3><p>One of the main advantages of using NIO instead
of the regular versions of the transport is that it can scale better and support larger number
of connections. The main limit in this scenario is the number of threads the system in using.
In blocking implementations of the transports, one thread is used per connection. In the NIO
implementation, there's a shared pool of threads that will take the load, so that number of
connections are not directly related to the number of threads used in the system.</p><p>You
can tune the number of threads used by the transport using the following system properties
(available since <strong>5.15.0</strong>)</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh">Property</
 th><th colspan="1" rowspan="1" class="confluenceTh">Default value</th><th
colspan="1" rowspan="1" class="confluenceTh">Description</th></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd">org.apache.activemq.transport.nio.SelectorManager.corePoolSize</td><td
colspan="1" rowspan="1" class="confluenceTd">10</td><td colspan="1" rowspan="1"
class="confluenceTd"><p>The number of threads to keep in the pool, even if they are
idle</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">org.apache.activemq.transport.nio.SelectorManager.maximumPoolSize</td><td
colspan="1" rowspan="1" class="confluenceTd">1024</td><td colspan="1" rowspan="1"
class="confluenceTd"><p>The maximum number of threads to allow in the pool</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>org.apache.activemq.transport.nio.SelectorManager.workQueueCapacity</p></td><td
colspan="1" rowspan="1" class="confluenceTd">&#160;0</td><td colspan="1" rowspan="1"
class="confluenceTd">&#160;The ma
 x work queue depth before growing the pool</td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><span>org.apache.activemq.transport.nio.SelectorManager.rejectWork</span></td><td
colspan="1" rowspan="1" class="confluenceTd">false</td><td colspan="1" rowspan="1"
class="confluenceTd">Allow work to be rejected with an IOException when capacity is reached
such that existing QOS can be preserved</td></tr></tbody></table></div><p>If
you want to scale your broker to support thousands of connections to it, you need to first
find the limits of number of threads JVM process is allowed to create. Then you can set these
properties to some value below that (broker need more threads to operate normally). For more
information on thread usage by destinations and how to limit those, please take a look at
<a shape="rect" href="scaling-queues.html">Scaling Queues</a>&#160;or&#160;<a
shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/activemq/trunk/assembly/src/sample-conf
 /activemq-scalability.xml">this configuration file</a>. For example you can add
the following</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">ACTIVEMQ_OPTS="$ACTIVEMQ_OPTS
-Dorg.apache.activemq.transport.nio.SelectorManager.corePoolSize=2000 -Dorg.apache.activemq.transport.nio.SelectorManager.maximumPoolSize=2000
-Dorg.apache.activemq.transport.nio.SelectorManager.workQueueCapacity=1024"</pre>
 </div></div><p>to the startup script (<code>${ACTIVEMQ_HOME}/bin/env</code>
for example)&#160;to have a constant pool of 2000 threads handling connections. With the
setting like this, the broker should be able to accept the number of connections up to the
system limits. Of course, accepting connections is just one part of the story, so there are
other limits to vertically scaling the broker.</p><p>&#160;</p></div>
         </td>



Mime
View raw message