qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Qpid > Qpid Java Broker Statistics
Date Wed, 09 Mar 2011 17:36:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2036/9/21/_/styles/combined.css?spaceKey=qpid&amp;forWysiwyg=true" type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Broker+Statistics">Qpid Java Broker Statistics</a></h2>
    <h4>Page  <b>added</b> by             <a href="https://cwiki.apache.org/confluence/display/~andrew.kennedy">Andrew Kennedy</a>
    </h4>
         <br/>
    <div class="notificationGreySide">
         <h1><a name="QpidJavaBrokerStatistics-BrokerStatistics"></a>Broker Statistics</h1>

<p>The following statistics are provided as a basic useful minimum.</p>

<ol>
	<li>Peak bytes per second</li>
	<li>Current bytes per second</li>
	<li>Total bytes</li>
	<li>Peak messages per second</li>
	<li>Current messages per second</li>
	<li>Total messages</li>
</ol>


<p>These statistics will be generated for both <b>delivered</b> and <b>received</b> messages, per <b>connection</b> and aggregated per <b>virtualhost</b> and also for the entire <b>broker</b>. Delivered messages are those that have been sent to a client by the broker, and may be counted more than once die to rollbacks and re-delivery. Received messages are those that are published by a client and received by the broker.</p>

<h2><a name="QpidJavaBrokerStatistics-Mechanism"></a>Mechanism</h2>

<p>The statistics are generated using a sample counter, which is thread-safe and is triggered on incoming message events. The totals for messages and data (bytes) are recorded as type <tt>long</tt> and the rates are recorded as <tt>double</tt> since they may be fractional.</p>

<p>The default sample period is one second, during which events are recorded cumulatively. This can be changed for <b>all</b> counters in the broker by setting the system property <tt>qpid.statistics.samplePeriod</tt>. Basically, rates are calculated as an average over this sample period, so if the traffic is very bursty, a small sample period will fail to capture events most of the time, and you will end up with inflated peak rates. Since we are calculating rates per-second, the sample period is 1000ms as a default, but if this is increased to, say, 10000ms then messages will be counted over ten second periods, and the resulting totals divided by ten to give the rate.</p>

<div class='panelMacro'><table class='infoMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/confluence/images/icons/emoticons/information.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Since <tt>qpid.statistics.samplePeriod</tt> is the cut-off point when the rates are calculated, stored, and then re-set, changing this property <em>should</em> affect performance. Increasing the value should improve throughput, decreasing should reduce it.</td></tr></table></div>

<p>When all statistics generation is enabled, there will be <b>12</b> counters that are used, since statistics are calculated for the product of the following sets:</p>

<p>{ Broker, Virtualhost, Connection } x { Delivery, Receipt } x { Messages, Data }</p>

<h2><a name="QpidJavaBrokerStatistics-Reporting"></a>Reporting</h2>

<p>If statistics are being generated for the broker or for virtualhosts then periodic reporting can be enabled. This is generated at specified intervals, with the option to reset the statistics after outputting the current data.</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>[Statistics-Reporting] BRK-1008 : received : 4.395 kB/s peak : 4500 bytes total
[Statistics-Reporting] BRK-1008 : delivered : 4.395 kB/s peak : 4500 bytes total
[Statistics-Reporting] BRK-1009 : received : 45 msg/s peak : 45 msgs total
[Statistics-Reporting] BRK-1009 : delivered : 45 msg/s peak : 45 msgs total
[Statistics-Reporting] VHT-1003 : localhost : received : 1.465 kB/s peak : 1500 bytes total
[Statistics-Reporting] VHT-1003 : localhost : delivered : 1.465 kB/s peak : 1500 bytes total
[Statistics-Reporting] VHT-1004 : localhost : received : 15 msg/s peak : 15 msgs total
[Statistics-Reporting] VHT-1004 : localhost : delivered : 15 msg/s peak : 15 msgs total
[Statistics-Reporting] VHT-1003 : test : received : 0.977 kB/s peak : 1000 bytes total
[Statistics-Reporting] VHT-1003 : test : delivered : 0.977 kB/s peak : 1000 bytes total
[Statistics-Reporting] VHT-1004 : test : received : 10 msg/s peak : 10 msgs total
[Statistics-Reporting] VHT-1004 : test : delivered : 10 msg/s peak : 10 msgs total
[Statistics-Reporting] VHT-1003 : development : received : 1.953 kB/s peak : 2000 bytes total
[Statistics-Reporting] VHT-1003 : development : delivered : 1.953 kB/s peak : 2000 bytes total
[Statistics-Reporting] VHT-1003 : development : received : 1.953 kB/s peak : 2000 bytes total
[Statistics-Reporting] VHT-1003 : development : delivered : 1.953 kB/s peak : 2000 bytes total
[Statistics-Reporting] VHT-1004 : development : received : 20 msg/s peak : 20 msgs total
[Statistics-Reporting] VHT-1004 : development : delivered : 20 msg/s peak : 20 msgs total
</pre>
</div></div>
<p><b>Sample statistics report log messages</b></p>

<p>The reported statistics are output using the operational logging mechanism, and can therefore be extracted from the log files using the same mechanisms as are currently used for other such messages. The new message types are as follows:</p>

<ul>
	<li><b>BRK-1008</b> - Broker data statistics (peak bytes per second and total bytes)</li>
	<li><b>BRK-1009</b> - Broker message statistics (peak messages per second and total messages)</li>
	<li><b>VHT-1003</b> - Virtualhost data statistics (peak bytes per second and total bytes)</li>
	<li><b>VHT-1004</b> - Virtualhost message statistics (peak messages per second and total messages)</li>
</ul>


<h1><a name="QpidJavaBrokerStatistics-Configuration"></a>Configuration</h1>

<p>The statistics generation will be configured via the <tt>config.xml</tt> broker configuration mechanism.</p>

<div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>config.xml</b></div><div class="codeContent panelContent">
<pre class="code-java">
&lt;statistics&gt;
    &lt;generation&gt;
        &lt;!-- <span class="code-keyword">default</span> <span class="code-keyword">false</span> --&gt;
        &lt;broker&gt;<span class="code-keyword">true</span>&lt;/broker&gt;
        &lt;virtualhosts&gt;<span class="code-keyword">true</span>&lt;/virtualhosts&gt;
        &lt;connections&gt;<span class="code-keyword">true</span>&lt;/connections&gt;
    &lt;/generation&gt;
    &lt;reporting&gt;
        &lt;period&gt;3600&lt;/period&gt;&lt;!-- seconds --&gt;
        &lt;reset&gt;<span class="code-keyword">true</span>&lt;/reset&gt;
    &lt;/reporting&gt;
&lt;/statistics&gt;
</pre>
</div></div>

<p>It is not possible to enable statistics generation for a single virtualhost - all virtualhosts will generate statistics if the <tt>//statistics/generation/virtualhosts</tt> element is set to <em>true</em>.</p>

<p>It only makes sense to enable reporting if either broker or virtualhosts have statistics generation enabled also. However, the broker will simply ignore the reporting configuration if no statistics are being generated. If the <tt>//statistics/reporting/reset</tt> element is set to <em>true</em> then after reporting on the statistics in the log, the statistics will be reset to zero for the entire broker.</p>

<p>Even if statistics generation is completely disabled, it is still possible to activate statistics on an individual connection, while the broker is running. The JMX attribute <b>statisticsEnabled</b> on a connection MBean can be set to <em>true</em> which will start statistics generation, and totals and rates will be calculated from this point onward, or until it is set to <em>false</em> again.</p>

<p>Additionally, the following two system properties can be set to configure the statistics counter:</p>

<ul>
	<li><tt>qpid.statistics.samplePeriod</tt> - sample period in ms - default <em>1000</em></li>
	<li><tt>qpid.statistics.disable</tt> - override configuration and disable statistics collection - default <em>false</em> (not set)</li>
</ul>


<p>These two properties are exposed on the <tt>StatisticsCounter</tt> class as static fields <tt>DEFAULT_SAMPLE_PERIOD</tt> and <tt>DISABLE_STATISTICS</tt>.</p>

<h1><a name="QpidJavaBrokerStatistics-Design"></a>Design</h1>

<h2><a name="QpidJavaBrokerStatistics-StatisticsCounterClass"></a><em>StatisticsCounter</em> Class</h2>

<p>This implements the counting of event data and generates the total and rate statistics. There should be one instance of this class per type of statistic, such as <em>messages</em> or <em>bytes</em>. The instance methods that are called to add an event are:</p>

<ul>
	<li><tt>void registerEvent()</tt><br/>
Registers a single event at the current system time, such as the arrival of a message.</li>
</ul>


<ul>
	<li><tt>void registerEvent(long value)</tt><br/>
Registers a cumulative value, such as the size of a message, at the current system time.</li>
</ul>


<ul>
	<li><tt>void registerEvent(long value, long timestamp)</tt><br/>
Registers a cumulative value at the specified time. As with the previous method, this could be <em>1</em>, which will allow timestamped single events to be registered if the no-argument version is not sufficient.</li>
</ul>


<p>There are three constructors:</p>

<ul>
	<li><tt>StatisticsCounter()</tt></li>
	<li><tt>StatisticsCounter(String name)</tt></li>
	<li><tt>StatisticsCounter(String name, long samplePeriod)</tt></li>
</ul>


<p>These are chained in that order, using a default name of <em>counter</em> and the default sample period of <em>2000</em> ms or set in the <tt>qpid.statistics.samplePeriod</tt> property.</p>

<p>To retrieve the data, there are methods to return the current rate, peak rate and total, as well as the start time, sample period and name of the counter, and also a method to reset the counter.</p>

<h2><a name="QpidJavaBrokerStatistics-StatisticsGathererInterface"></a><em>StatisticsGatherer</em> Interface</h2>

<p>This is implemented by the broker business object that is generating statistics. It provides the following methods:</p>

<ul>
	<li><tt>void initialiseStatistics()</tt></li>
	<li><tt>void registerMessageReceived(long messageSize, long timestamp)</tt></li>
	<li><tt>void registerMessageDelivered(long messageSize)</tt></li>
	<li><tt>StatisticsCounter getMessageDeliveryStatistics()</tt></li>
	<li><tt>StatisticsCounter getDataDeliveryStatistics()</tt></li>
	<li><tt>StatisticsCounter getMessageReceiptStatistics()</tt></li>
	<li><tt>StatisticsCounter getDataReceiptStatistics()</tt></li>
	<li><tt>void resetStatistics()</tt></li>
	<li><tt>void setStatisticsEnabled(boolean enabled)</tt></li>
	<li><tt>boolean isStatisticsEnabled()</tt></li>
</ul>


<p>These statistics are exposed using the separate JMX Mbean interfaces detailed below, which calls these methods to retrieve the underlying <tt>StatisticsCounter</tt> objects and return their attributes. This interface gives a standard way for parts of the broker to set up and configure statistics generation.</p>

<p>When creating these objects, there should be a parent/child relationship between them, normally from <em>broker</em> to <em>virtualhost</em> to <em>connection</em>. This means that the lowest level gatherer can record statistics (if enabled) and also pass on the notification to its parent object to allow higher level aggregation of statistics. When resetting statistics, this works in the opposite direction, with higher level gatherers also resetting all of their child objects. Note that this parent/choild relationship is never explicitly specified, and is dependant on the implementation of <tt>registerMessageDelivery</tt> and <tt>resetStatistics</tt> in order to allow more flexibility.</p>

<h2><a name="QpidJavaBrokerStatistics-JMXInterface"></a>JMX Interface</h2>

<p>The Qpid JMX interface level that supports statistics is <em>1.9</em>. Each object (MBean) that can generate statistics will add the following attributes and operations:</p>

<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'>Operation</th>
<th class='confluenceTh'>Description</th>
</tr>
<tr>
<td class='confluenceTd'><b>resetStatistics</b></td>
<td class='confluenceTd'>Reset the statistics counters for this object, and all children.</td>
</tr>
</tbody></table>
</div>


<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'>Attribute</th>
<th class='confluenceTh'>Permissions</th>
<th class='confluenceTh'>Description</th>
</tr>
<tr>
<td class='confluenceTd'><b>peakMessageDeliveryRate</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Peak number of messages delivered per second</td>
</tr>
<tr>
<td class='confluenceTd'><b>peakDataDeliveryRate</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Peak number of bytes delivered per second</td>
</tr>
<tr>
<td class='confluenceTd'><b>messageDeliveryRate</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Current number of messages delivered per second</td>
</tr>
<tr>
<td class='confluenceTd'><b>dataDeliveryRate</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Current number of bytes delivered per second</td>
</tr>
<tr>
<td class='confluenceTd'><b>totalMessagesDelivered</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Total number of messages delivered since start or reset</td>
</tr>
<tr>
<td class='confluenceTd'><b>totalDataDelivered</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Total number of bytes delivered since start or reset</td>
</tr>
<tr>
<td class='confluenceTd'><b>peakMessageReceiptRate</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Peak number of messages received per second</td>
</tr>
<tr>
<td class='confluenceTd'><b>peakDataReceiptRate</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Peak number of bytes received per second</td>
</tr>
<tr>
<td class='confluenceTd'><b>messageReceiptRate</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Current number of messages received per second</td>
</tr>
<tr>
<td class='confluenceTd'><b>dataReceiptRate</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Current number of bytes received per second</td>
</tr>
<tr>
<td class='confluenceTd'><b>totalMessagesReceived</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Total number of messages received since start or reset</td>
</tr>
<tr>
<td class='confluenceTd'><b>totalDataReceived</b></td>
<td class='confluenceTd'><em>R</em></td>
<td class='confluenceTd'>Total number of bytes received since start or reset</td>
</tr>
<tr>
<td class='confluenceTd'><b>statisticsEnabled</b></td>
<td class='confluenceTd'><em>R</em> (<em>W</em> <b>Connections only</b>)</td>
<td class='confluenceTd'>Is statistics generation enabled or disabled </td>
</tr>
</tbody></table>
</div>


<p>The following MBeans have had statistics attributes added:</p>

<ul>
	<li><b>ServerInformation</b><br/>
The entire broker, statistics for all virtualhosts. The totals for the broker will be equal to the sum of the totals for all virtualhosts. Rates for the broker include messages from all virtualhosts, so the broker peak can be higher than individual virtualhosts, and possibly also higher than the sum, due to slight timing differences. This is to be expected.<br/>
<tt>org.apache.qpid:type=ServerInformation,name=ServerInformation,&#42;</tt></li>
</ul>


<ul>
	<li><b>ManagedBroker</b><br/>
This is just a misleadingly named virtualhost. Note that the sum of all connections statistics will <b>not</b> always equal the statistics for the virtualhost, as connection MBeans are discarded when the connection is closed.<br/>
<tt>org.apache.qpid:type=VirtualHost.VirtualHostManager,VirtualHost=&#42;,&#42;</tt></li>
</ul>


<ul>
	<li><b>ManagedConnection</b><br/>
Individual connections, which can be selected on a per-virtualhost basis. The name of a connection is usually the Java <tt>toString()</tt> representation of the address of the remote internet socket making the connection, so it is usually not possible to determine these in advance. These allow enabling and disabling of statistics generation.<br/>
<tt>org.apache.qpid:type=VirtualHost.Connection,VirtualHost=&#42;,name=&#42;</tt></li>
</ul>


<p>The JMX attributes that record statistics are always present, and will have a value of <em>0</em>/<em>0.0</em> if generation is not enabled, and the <b>statisticsEnabled</b> attribute will be set to <em>false</em>.</p>

<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/confluence/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>The <tt>qpid.statistics.disable</tt> system property will override all configuration on the broker. All attributes will be reported as <em>0</em>/<em>0.0</em> and JMX will show statistics as being disabled via the <b>statisticsEnabled</b> property, although it will be possible to selectively enable generation on a per-connection basis.</td></tr></table></div>

<h2><a name="QpidJavaBrokerStatistics-Usage"></a>Usage</h2>

<p>The JMX JConsole application can be used to view the attributes, both as discrete values or as graphs. Sample output is shown below, illustrating the virtualhost statistics for a broker with a producer and a consumer attached and sending messsages.</p>

<p><span class="error">Unable to render embedded object: File (jconsole-statistics-zero.png) not found.</span><br/>
<b>Virtualhost statistics attributes at broker startup</b></p>

<p><span class="error">Unable to render embedded object: File (jconsole-statistics-graphs.png) not found.</span><br/>
<b>Virtualhost statistics graphs and attributes after sending and receiving messages through the broker</b></p>

<h1><a name="QpidJavaBrokerStatistics-Testing"></a>Testing</h1>

<p>One caveat related to testing is that these statistics, apart from totals, are by their nature time dependent, and subject to race conditions, where sending messages as part of a test can overlap two sample periods, instead of one, causing seemingly incorrect results. </p>

<h2><a name="QpidJavaBrokerStatistics-Unit"></a>Unit</h2>

<p>The <tt>StatisticsCounter</tt> class is suitable for unit testing. Tests checking class creation and operation check the total, rate and peak data, as well as other class properties. It is difficult to write a test to provably show thread safety when updating the counter with new events, but there are tests to check that out-of-order events will not cause problems with the data generated.</p>

<h2><a name="QpidJavaBrokerStatistics-System"></a>System</h2>

<p>System testing covers the generation of statistics using a running broker, as well as the configuration mechanisms and the operation of the JMX interface to the data and the operational logging output. The following system tests have been written, all using a shared parent test case class, <tt>MessageStatisticsTestCase</tt> which sets up the JMX connection to the broker.</p>

<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/confluence/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>In order for these JMX based tests to work correctly with the <em>default</em> test profile, a fix had to be back-ported from trunk which disables the use of a custom <tt>ServerSocketFactory</tt> in the JMX registry. The property that disables this is set only in the <tt>JMXUtils</tt> helper class, and should not be used in normal broker operation.</td></tr></table></div>

<ul>
	<li><tt>MessageStatisticsTest</tt></li>
	<li><tt>MessageStatisticsDeliveryTest</tt></li>
	<li><tt>MessageStatisticsReportingTest</tt></li>
	<li><tt>MessageConnectionStatisticsTest</tt></li>
	<li><tt>MessageStatisticsConfigurationTest</tt></li>
</ul>


<p>These tests can be run with the following command, from the <em>systests</em> module directory:<br/>
<tt><em>$</em> <b>ant test -Dtest=Message&#42;Statistics&#42;Test</b></tt></p>

<h2><a name="QpidJavaBrokerStatistics-Performance"></a>Performance</h2>

<p>To measure performance, a release of <em>2.6.0.7</em> was generated, using the standard release mechanism. The data should be compared with the previous <a href="/confluence/pages/createpage.action?spaceKey=qpid&amp;title=2.6.0.6+Testing&amp;linkCreation=true&amp;fromPageId=25204144" class="createlink">results</a> for the <em>2.6.0.6</em> release. The performance test suite was run on <tt>noc-qpiddev02.jpmorganchase.com</tt> with the broker running on <tt>noc-qpiddev01.jpmorganchase.com</tt>. Statistics were enabled on the broker by editing the <tt>etc/persistent_config.xml</tt> file to set statistics generation to <em>true</em> for the broker, virtualhosts and connections, as well as to report every hour (without resetting the statistics). The <em>Disabled</em> configuration used the provided default configuration file, and the <em>Broker Only</em> configuration used the same as the first set of tests, but with the <tt>//statistics/generation/virtualhosts</tt> and <tt>//statistics/generation/connections</tt> elements set to <em>false</em>.</p>

<p>The following command was executed for each of the configurations, and the results are aggregated into the tables below:<br/>
<tt><em>$</em> <b>./Throughput.sh</b></tt></p>

<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/confluence/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td><b>Accuracy</b><br />The measured standard deviation of these results is <b>2.2%</b> (about <b>500</b>) of the mean (about <b>23000</b>), based on ten sample runs of the <em>TTBT-TX</em> test with no statistics generation enabled. For the <em>TTBT-NA</em> test, a set of <span class="error">&#91;102 test runs|^throughput.csv&#93;</span> indicated that the standard deviation was around <b>0.8%</b> of the mean, with a range of <b>3.8%</b> of the mean between the minimum and maximum result.</td></tr></table></div>

<h3><a name="QpidJavaBrokerStatistics-InitialResults"></a>Initial Results</h3>

<p>These results use the code from SVN revision r1033077, annd were generated on the 09 and 10 November 2010.</p>

<h4><a name="QpidJavaBrokerStatistics-ThroughputNumbers"></a>Throughput Numbers</h4>

<table cellpadding="3" cellspacing="0" border="1"><tr><td bgcolor="#eeeeff"><b>Test</b><br class="atl-forced-newline" />&nbsp;</td><td bgcolor="#eeeeff"><b>Thoughput</b><br class="atl-forced-newline" />&nbsp;</td><td bgcolor="#eeeeff"><b>Throughput</b><br class="atl-forced-newline" />Broker Only</td><td bgcolor="#eeeeff"><b>Throughput</b><br class="atl-forced-newline" />Disabled</td></tr>
<tr><td>PQBT-AA-Qpid-01</td><td>2937.3007</td><td>0</td><td>3239.986</td></tr>
<tr><td>PQBT-TX-Qpid-01</td><td>3142.3297</td><td>0</td><td>3240.4037</td></tr>
<tr><td>PTBT-AA-Qpid-01</td><td>3817.1709</td><td>3897.9127</td><td>3941.363</td></tr>
<tr><td>PTBT-TX-Qpid-01</td><td>3971.9589</td><td>0</td><td>4087.7404</td></tr>
<tr><td>TQBT-AA-Qpid-01</td><td>52299.27</td><td>0</td><td>53195.957</td></tr>
<tr><td>TQBT-NA-Qpid-01</td><td>50979.767</td><td>48090.19</td><td>51696.26</td></tr>
<tr><td>TQBT-TX-Qpid-01</td><td>7321.2233</td><td>0</td><td>7438.8633</td></tr>
<tr><td>TTBT-AA-Qpid-01</td><td>86934.654</td><td>0</td><td>92742.66</td></tr>
<tr><td>TTBT-NA-Qpid-01</td><td>103829.22</td><td>0</td><td>128478.24</td></tr>
<tr><td>TTBT-TX-Qpid-01</td><td>21685.606</td><td>0</td><td>22985.97</td></tr></table>

<p>There was no obvious difference between broker only and all statistics, so that testing was discontinued.</p>

<h4><a name="QpidJavaBrokerStatistics-Comparisonwithpreviousrelease%3A"></a>Comparison with previous release:</h4>

<table cellpadding="3" cellspacing="0" border="1"><tr><td bgcolor="#eeeeff"><b>Test</b><br class="atl-forced-newline" />&nbsp;</td><td bgcolor="#eeeeff"><b>2.6.0.6</b><br class="atl-forced-newline" />&nbsp;</td><td bgcolor="#eeeeff"><b>2.6.0.7</b><br class="atl-forced-newline" />&nbsp;</td><td bgcolor="#eeeeff"><b>Change</b><br class="atl-forced-newline" />&nbsp;</td><td bgcolor="#eeeeff"><b>2.6.0.7</b><br class="atl-forced-newline" />Disabled</td><td bgcolor="#eeeeff"><b>Change</b><br class="atl-forced-newline" />Disabled</td></tr>
<tr><td>PQBT-AA-Qpid-01</td><td>3214.728</td><td>2937.3007</td><td>-8.63%</td><td>3239.986</td><td>0.79%</td></tr>
<tr><td>PQBT-TX-Qpid-01</td><td>3224.1871</td><td>3142.3297</td><td>-2.54%</td><td>3240.4037</td><td>0.50%</td></tr>
<tr><td>PTBT-AA-Qpid-01</td><td>4069.4785</td><td>3817.1709</td><td>-6.20%</td><td>3941.363</td><td>-3.15%</td></tr>
<tr><td>PTBT-TX-Qpid-01</td><td>4088.1968</td><td>3971.9589</td><td>-2.84%</td><td>4087.7404</td><td>-0.1%</td></tr>
<tr><td>TQBT-AA-Qpid-01</td><td>51871.49</td><td>52299.27</td><td>0.82%</td><td>53195.957</td><td>2.55%</td></tr>
<tr><td>TQBT-NA-Qpid-01</td><td>54278.095</td><td>50979.767</td><td>-6.08%</td><td>51696.26</td><td>-4.76%</td></tr>
<tr><td>TQBT-TX-Qpid-01</td><td>7496.785</td><td>7321.2233</td><td>-2.34%</td><td>7438.8633</td><td>-0.77%</td></tr>
<tr><td>TTBT-AA-Qpid-01</td><td>94392.1</td><td>86934.654</td><td>-7.90%</td><td>92742.66</td><td>-1.75%</td></tr>
<tr><td>TTBT-NA-Qpid-01</td><td>129089.54</td><td>103829.22</td><td>-19.57%</td><td>128478.24</td><td>-0.47%</td></tr>
<tr><td>TTBT-TX-Qpid-01</td><td>23134.289</td><td>21685.606</td><td>-6.26%</td><td>22985.97</td><td>-0.64%</td></tr>
<tr><td colspan="2"></td><td bgcolor="#eeeeff"><b>Average</b></td><td><b>-6.84%</b></td><td bgcolor="#eeeeff"><b>Average</b></td><td><b>-0.77%</b></td></tr></table>

<h4><a name="QpidJavaBrokerStatistics-Analysis"></a>Analysis</h4>

<div class='panelMacro'><table class='warningMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/confluence/images/icons/emoticons/forbidden.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>As can be seen, this results in an average of around <b>7%</b> reduction in throughput with all statistics generation enabled, and less that <b>1%</b> reduction with them disabled. One anomaly that stands out is the <em>TTBT_NA</em> test (transient, non-acknowledge messages) which shows a nearly <b>20%</b> decrease in throughput, which warrants further investigation. However this is obviously too great a penalty, and will require code changes and further investigation and testing.</td></tr></table></div>

<p>Further testing with different combinations of broker, virtualhost and connection statistics enabled will need to be carried out to determine where the greatest penalty in performance lies. Based on this, there may be changes required to the <tt>StatisticsCounter</tt> class, or the propagation mechanism that links child and parent counter objects.</p>

<p>It is also important to determine what the maximum acceptable loss of throughput is to a customer. It would seem desirable to have less that <b>5%</b> decreate in throughput due to statistics generation, however it should be noted that a performance penalty is inevitable when adding code to the message delivery and receipt paths in the broker, and the aim is only to minimise this, not to eliminate it.</p>

<h3><a name="QpidJavaBrokerStatistics-FurtherTesting"></a>Further Testing</h3>

<p>The <b>7%</b> performance loss was felt to be unacceptable, so modifications were made to the <tt>StatisticsCounter</tt> code to reduce the time spend carrying out computations. The following changes were made:</p>

<ol>
	<li>The system property <tt>qpid.statistics.samplePeriod</tt> was changed from <em>1000</em> to <em>2000</em> and <em>5000</em>.</li>
	<li>The code in <tt>StatisticsCounter</tt> was modified to defer more calculation to the end of a sample period.</li>
</ol>


<h4><a name="QpidJavaBrokerStatistics-ThroughputNumbers"></a>Throughput Numbers</h4>

<p>The same <em>2.6.0.7</em> broker with <em>QPID_OPTS</em> set to <tt>-Dqpid.statistics.samplePeriod=N</tt> where <em>N</em> is <em>2000</em> or <em>5000</em>.</p>

<table cellpadding="3" cellspacing="0" border="1"><tr><td bgcolor="#eeeeff"><b>Test</b><br class="atl-forced-newline" />&nbsp;</td><td bgcolor="#eeeeff"><b>2.6.0.6</b><br class="atl-forced-newline" />&nbsp;</td><td bgcolor="#eeeeff"><b>2.6.0.7</b><br class="atl-forced-newline" />2000</td><td bgcolor="#eeeeff"><b>Change</b><br class="atl-forced-newline" />2000</td><td bgcolor="#eeeeff"><b>2.6.0.7</b><br class="atl-forced-newline" />5000</td><td bgcolor="#eeeeff"><b>Change</b><br class="atl-forced-newline" />5000</td></tr>
<tr><td>PQBT-AA-Qpid-01</td><td>3214.728</td><td>3198.1702</td><td>-0.52%</td><td>2970.78</td><td>-7.59%</td></tr>
<tr><td>PQBT-TX-Qpid-01</td><td>3224.1871</td><td>3214.087</td><td>-0.31%</td><td>2875.1144</td><td>-10.82%</td></tr>
<tr><td>PTBT-AA-Qpid-01</td><td>4069.4785</td><td>4030.176</td><td>-0.97%</td><td>3872.7224</td><td>-4.83%</td></tr>
<tr><td>PTBT-TX-Qpid-01</td><td>4088.1968</td><td>4175.8924</td><td>2.15%</td><td>3962.1336</td><td>-3.08%</td></tr>
<tr><td>TQBT-NA-Qpid-01</td><td>54278.095</td><td>52546.314</td><td>-3.19%</td><td>48368.572</td><td>-10.89%</td></tr>
<tr><td>TTBT-TX-Qpid-01</td><td>23134.289</td><td>22086.33</td><td>-4.53%</td><td>18947.935</td><td>-18.10%</td></tr>
<tr><td colspan="2"></td><td bgcolor="#eeeeff"><b>Average</b></td><td><b>-1.23%</b></td><td bgcolor="#eeeeff"><b>Average</b></td><td><b>-9.22%</b></td></tr></table>

<p>Old is an unmodified <em>2.6.0.7</em> broker, the new broker has <em>QPID_OPTS</em> set to <tt>-Dqpid.statistics.samplePeriod=5000</tt> and some changes to the <tt>StatisticsCounter</tt> class that move computation to the end of the sample period, all three have <em>QPID_JAVA_MEM</em> set to <tt>-Xmx2g</tt>. Results are the average of three runs.</p>

<table cellpadding="3" cellspacing="0" border="1"><tr><td bgcolor="#eeeeff"><b>TTBT-NA-Qpid-01</b></td><td bgcolor="#eeeeff"><b>Result</b></td><td bgcolor="#eeeeff"><b>Change</b></td></tr>
<tr><td bgcolor="#eeeeff"><b>2.6.0.6</b></td><td>113206</td><td>0.0%</td></tr>
<tr><td bgcolor="#eeeeff"><b>2.6.0.7</b> Old</td><td>103077</td><td>-8.9%</td></tr>
<tr><td bgcolor="#eeeeff"><b>2.6.0.7</b> New 5s</td><td>106202</td><td>-6.1%</td></tr>
<tr><td bgcolor="#eeeeff"><b>2.6.0.7</b> New 10s</td><td>104196</td><td>-8.0%</td></tr></table>

<h3><a name="QpidJavaBrokerStatistics-MoreTests"></a>More Tests</h3>

<p>Two 5 minute runs of a simple test, producing and consuming messages as fast as possible in a single thread. This was run on a HP DL585, Quad dual-core 2.2GHz Opteron, 8Gb, hence the difference in reported rates.</p>

<ul>
	<li>Statistics Configuration Enabled<br/>
<tt><em>$</em> <b>QPID_OPTS=-Dqpid.statistics.samplePeriod=2500 QPID_JAVA_MEM=-Xmx4g ./qpid-server</b></tt><br/>
3792.9 msgs/s</li>
	<li>Statistics Configuration Enabled<br/>
<tt><em>$</em> <b>QPID_OPTS=-Dqpid.statistics.samplePeriod=500 QPID_JAVA_MEM=-Xmx4g ./qpid-server</b></tt><br/>
3961.8 msgs/s</li>
	<li>Statistics Configuration Enabled<br/>
<tt><em>$</em> <b>QPID_OPTS=-Dqpid.statistics.samplePeriod=30000 QPID_JAVA_MEM=-Xmx4g ./qpid-server</b></tt><br/>
3999.3 msgs/s</li>
	<li>Statistics Configuration Enabled<br/>
<tt><em>$</em> <b>QPID_OPTS=-Dqpid.statistics.disable=true QPID_JAVA_MEM=-Xmx4g ./qpid-server</b></tt><br/>
4156.3 msgs/s</li>
	<li>Stock Apache 0.5 Download - <a href="http://apache.mirror.anlx.net//qpid/0.5/qpid-java-broker-0.5.tar.gz" class="external-link" rel="nofollow">http://apache.mirror.anlx.net//qpid/0.5/qpid-java-broker-0.5.tar.gz</a><br/>
<tt><em>$</em> <b>QPID_JAVA_MEM=-Xmx4g ./qpid-server</b></tt><br/>
4068.3 msgs/s</li>
</ul>


<div class='panelMacro'><table class='infoMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/confluence/images/icons/emoticons/information.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>These results would seem to indicate that the act of generating statistics is causing the slowdown, rather than updating the peak value at the end of a sample period. Additionally, the results for the <b>single-threaded</b> testing are much closer, suggesting that lock contention with many connections is an issue.</td></tr></table></div>

<h3><a name="QpidJavaBrokerStatistics-Profiling"></a>Profiling</h3>

<p>To properly determine hot-spots in the code, a profiling run was made using the <em>YourKit</em> profiler. The simple test used in the previous section was run with the profiler attached, and CPU statistics were collated. The profiler detected the following hotspots:</p>

<ul>
	<li><tt>StatisticsCounter.registerEvent</tt> - <b>4%</b></li>
	<li><tt>AtomicLong.addAndGet</tt> - <b>3%</b></li>
	<li><tt>AtomicLong.compareAndSet</tt> - <b>2%</b></li>
</ul>


<p>Since the <tt>AtomicLong</tt> calls are made inside <tt>registerEvent</tt>, it seems that this is where the CPU is spending the extra time that is causing the slowdown. In order to mitigate this, the <tt>registerEvent</tt> method was changed to be <tt>synchronized</tt> and the internal logic changed to use primitive <tt>long</tt> types and standard arithmentic operations. After this change, the profiler no longer showed the <tt>registerEvent</tt> as a hotspot in the code when another test run was made.</p>

<p>The updated code was copied to the broker being used for throughput testing, and the <b>TTBT-NA-Qpid-01</b> test was re-run, with results shown below (again, an average of three runs was taken).</p>

<table cellpadding="3" cellspacing="0" border="1"><tr><td bgcolor="#eeeeff"><b>TTBT-NA-Qpid-01</b></td><td bgcolor="#eeeeff"><b>Result</b></td><td bgcolor="#eeeeff"><b>Change</b></td></tr>
<tr><td bgcolor="#eeeeff"><b>2.6.0.6</b></td><td>113206</td><td>0.0%</td></tr>
<tr><td bgcolor="#eeeeff"><b>2.6.0.7</b> Latest</td><td>103698</td><td>-8.3%</td></tr></table>

<p>Finally, the single-threaded test was also run against <em>2.6.0.6</em> and the latest <em>2.6.0.7</em> build, with the following results:</p>

<table cellpadding="3" cellspacing="0" border="1"><tr><td bgcolor="#eeeeff"><b>TTBT-NA-Qpid-01</b></td><td bgcolor="#eeeeff"><b>Msgs/Second</b></td><td bgcolor="#eeeeff"><b>Change</b></td></tr>
<tr><td bgcolor="#eeeeff"><b>2.6.0.6</b></td><td>1714.5</td><td>0.0%</td></tr>
<tr><td bgcolor="#eeeeff"><b>2.6.0.7</b> Latest</td><td>1660</td><td>-3.2%</td></tr></table>

<p>In order to more fully test this, the script which starts the <em>TTBT-NA</em> test, and the <b>Throughput.sh</b> sctipt itself, were copied, and modified. A series of scripts, <b>STAT-</b><em>XX</em><b>.sh</b>, was created, consisting of identical calls to the <em>TTBT-NA</em> test apart from the number of consumers, which varied from <em>01</em> to <em>16</em> and is represented by <em>XX</em>, and a <b>Statistics.sh</b> script was created which calls each of these in turn.</p>

<p>The <em>STAT</em> throughput tests were run against a standard <em>2.6.0.6</em> broker and the <em>2.6.0.7</em> build with all statistics generation enabled. It is expected that the difference in throughput should <em>increase</em> as the number of consumers increases. Note that these tests were only run <b>once</b> so are not as accurate as the averaged, multi-run datasets.</p>

<h4><a name="QpidJavaBrokerStatistics-2.6.0.6ThroughputNumbers"></a>2.6.0.6 Throughput Numbers</h4>

<p><tt><em>$</em> <b>QPID_JAVA_MEM=-Xmx2g ./qpid-server -c ../etc/persistent_config.xml</b></tt></p>

<table cellpadding="3" cellspacing="0" border="1"><tr><td bgcolor="#eeeeff"><b>Test</b></td><td bgcolor="#eeeeff"><b>Thoughput</b></td></tr>
<tr><td>STAT-01</td><td>57415.543</td></tr>
<tr><td>STAT-02</td><td>92730.82</td></tr>
<tr><td>STAT-03</td><td>105619.415</td></tr>
<tr><td>STAT-04</td><td>116192.78</td></tr>
<tr><td>STAT-05</td><td>119669.87</td></tr>
<tr><td>STAT-06</td><td>122700.195</td></tr>
<tr><td>STAT-07</td><td>111541.725</td></tr>
<tr><td>STAT-08</td><td>126887.405</td></tr>
<tr><td>STAT-09</td><td>110207.38</td></tr>
<tr><td>STAT-10</td><td>122272.66</td></tr>
<tr><td>STAT-11</td><td>123028.33</td></tr>
<tr><td>STAT-12</td><td>127724.23</td></tr>
<tr><td>STAT-13</td><td>114467.72</td></tr>
<tr><td>STAT-14</td><td>128505.86</td></tr>
<tr><td>STAT-15</td><td>116783.16</td></tr>
<tr><td>STAT-16</td><td>127264.14</td></tr></table>

<h4><a name="QpidJavaBrokerStatistics-2.6.0.7ThroughputNumbers"></a>2.6.0.7 Throughput Numbers</h4>

<p><tt><em>$</em> <b>QPID_OPTS=-Dqpid.statistics.samplePeriod=5000 QPID_JAVA_MEM=-Xmx2g ./qpid-server -c ../etc/persistent_config.xml</b></tt></p>

<table cellpadding="3" cellspacing="0" border="1"><tr><td bgcolor="#eeeeff"><b>Test</b></td><td bgcolor="#eeeeff"><b>Thoughput</b></td><td bgcolor="#eeeeff"><b>Change</b></td></tr>
<tr><td>STAT-01</td><td>57101.006</td><td>-0.5%</td></tr>
<tr><td>STAT-02</td><td>83016.304</td><td>-10.5%</td></tr>
<tr><td>STAT-03</td><td>92533.17</td><td>-12.4%</td></tr>
<tr><td>STAT-04</td><td>99060.04</td><td>-14.8%</td></tr>
<tr><td>STAT-05</td><td>103271.49</td><td>-13.7%</td></tr>
<tr><td>STAT-06</td><td>103339.02</td><td>-15.8%</td></tr>
<tr><td>STAT-07</td><td>103619.804</td><td>-7.1%</td></tr>
<tr><td>STAT-08</td><td>105613.2</td><td>-16.8%</td></tr>
<tr><td>STAT-09</td><td>104110.99</td><td>-5.5%</td></tr>
<tr><td>STAT-10</td><td>107108.84</td><td>-12.4%</td></tr>
<tr><td>STAT-11</td><td>106436.25</td><td>-13.5%</td></tr>
<tr><td>STAT-12</td><td>108537.865</td><td>-15.0%</td></tr>
<tr><td>STAT-13</td><td>104056.22</td><td>-9.1%</td></tr>
<tr><td>STAT-14</td><td>108337.49</td><td>-15.7%</td></tr>
<tr><td>STAT-15</td><td>106900.96</td><td>-8.5%</td></tr>
<tr><td>STAT-16</td><td>109222.84</td><td>-14.2%</td></tr></table>

<p>Although it is difficult to draw any real or meaningful conclusions from these results, note that <b>single</b> consumer performance degradation is negligible.</p>

<p>A useful further test would be to run the <em>2.6.0.7</em> broker with only connection-level statistics being generated? This ought to remove the contention for the lock on the counters for virtualhosts and the broker when many consumers are being delivered to.</p>

<h4><a name="QpidJavaBrokerStatistics-2.6.0.7ThroughputNumbers"></a>2.6.0.7 Throughput Numbers</h4>

<p><tt><em>$</em> <b>QPID_OPTS=-Dqpid.statistics.samplePeriod=5000 QPID_JAVA_MEM=-Xmx2g ./qpid-server -c ../etc/connection_config.xml</b></tt></p>

<table cellpadding="3" cellspacing="0" border="1"><tr><td bgcolor="#eeeeff"><b>Test</b></td><td bgcolor="#eeeeff"><b>Thoughput</b></td><td bgcolor="#eeeeff"><b>Change</b></td></tr><td>STAT-01</td><td>55884.613</td><td>-2.7%</td><tr></tr><td>STAT-02</td><td>91857.41</td><td>-0.9%</td><tr></tr><td>STAT-07</td><td>114754.22</td><td>2.9%</td><tr></tr><td>STAT-08</td><td>117917.595</td><td>-7.1%</td><tr></tr><td>STAT-09</td><td>114506.71</td><td>3.9%</td><tr></tr><td>STAT-10</td><td>122330.33</td><td>0.0%</td><tr></tr><td>STAT-11</td><td>118661.09</td><td>-3.5%</td><tr></tr><td>STAT-13</td><td>116632.744</td><td>1.9%</td><tr></tr><td>STAT-15</td><td>118917.79</td><td>1.8%</td><tr></tr><td>STAT-16</td><td>120704.68</td><td>-5.2%</td><tr></tr></table>

<h2><a name="QpidJavaBrokerStatistics-Conclusion%3F"></a>Conclusion?</h2>

<p>It would appear that there is a penalty of a few percent (up to 4%) for a single thread, rising to over 10% when there are many threads. Further testing will be required to determine how the number of connections (i.e. threads) causes the performance to vary. This is, of course, hampered by the fact that the throughput tests exhibit up to 4% variability between the minimum and maximum results for a particular test.</p>

<p>Additionally, it is unclear which of the two mechanisms (<tt>AtomicLong</tt> versus synchronized <tt>registerEvent</tt> method) used in the counter is preferable. For the many-threaded, multi-consumer/producer case the <tt>AtomicLong</tt> seems the better choice, for a single producer/consumer the synchronized <tt>registerEvent</tt> method is better.</p>

<p>Another point to note is that the actual per-message latency increase is quite small, and it is only when sending large numbers of messages <em>using many connections</em> that the degradation comes into play, and the ratio of messages to data is small, i.e. the <b>data</b> throughput does not concern us, it is purely the number of messages. This means that for most applications there should not be a noticeable difference in performance, with any small change in per message latency being eaten up in noise.</p>

<p>Another point to note is that in these test garbage collection</p>

<h3><a name="QpidJavaBrokerStatistics-FurtherModifications"></a>Further Modifications</h3>

<p>This data was generated after modifying the broker code to place statistics recording for message <b>delivery</b> after the message is enqueued at the broker (or at least, after an attempt has been made to do so). </p>

<table cellpadding="3" cellspacing="0" border="1"><tr><td bgcolor="#eeeeff"><b>Test</b></td><td bgcolor="#eeeeff"><b>2.6.0.7</b></td><td bgcolor="#eeeeff"><b>2.6.0.6</b></td><td bgcolor="#eeeeff"><b>2.6.0.7</b></td><td bgcolor="#eeeeff"><b>2.6.0.7</b></td><td bgcolor="#eeeeff"><b>Disabled</b></td></tr>
<tr><td>PQBT-AA-Qpid-01</td><td>2777.4448</td><td>2696.0464</td><td>2702.624</td><td>2815.1379</td><td>2730.4008</td></tr>
<tr><td>PQBT-TX-Qpid-01</td><td>3206.5027</td><td>3147.2404</td><td>3179.9607</td><td>2701.3173</td><td>3148.375</td></tr>
<tr><td>PTBT-AA-Qpid-01</td><td>4014.191</td><td>3977.7153</td><td>3902.3087</td><td>3983.5536</td><td>3996.9091</td></tr>
<tr><td>PTBT-TX-Qpid-01</td><td>4023.8338</td><td>3996.622</td><td>4079.2136</td><td>3694.2487</td><td>4006.0062</td></tr>
<tr><td>TQBT-AA-Qpid-01</td><td>47845.87</td><td>51156.82</td><td>52660.16</td><td>45339.924</td><td>51316.2</td></tr>
<tr><td>TQBT-NA-Qpid-01</td><td>48345.562</td><td>47846.085</td><td>48281.647</td><td>49123.188</td><td>47374.016</td></tr>
<tr><td>TQBT-TX-Qpid-01</td><td>6301.3253</td><td>7262.565</td><td>7209.0416</td><td>6326.9844</td><td>7234.8924</td></tr>
<tr><td>TTBT-AA-Qpid-01</td><td>78419.44</td><td>89033.62</td><td>79150.925</td><td>80203.896</td><td>90342.84</td></tr>
<tr><td>TTBT-NA-Qpid-01</td><td>97468.78</td><td>110630.585</td><td>97623.314</td><td>98914.57</td><td>120317.604</td></tr>
<tr><td>TTBT-TX-Qpid-01</td><td>18498.884</td><td>22650.204</td><td>21379.168</td><td>18915.474</td><td>22702.417</td></tr></table>

<p>As a cross-check, the tests were repeated using a stock <em>2.6.0.6</em> broker, then again (twice actually), with the <em>2.6.0.7</em> broker, like the first time, in case there are any environmental factors that are skewing the results. And finally, with the <em>2.6.0.7</em> broker, but with statisatics generation disabled.</p>

<p>These results show that the persistent testing has results that are about the same for both versions, whether the statistics are enbled or disabled. This is due to the naturally lower throughput causing less contention and allowing the statistics generation to run unimpeded. The transient tests get worse with statistics generation enabled, due to the much higher message throughput and the fact that may messages are trying to update the counters at the same time.</p>

<h3><a name="QpidJavaBrokerStatistics-Latencey"></a>Latencey</h3>

<p>As a general recommendation, I would suggest that statistics generation is only enabled in cases of low message (count, not size) traffic, where the broker is not being 100% ustilised in terms of CPU. Persistant messaging is nescessarily I/O bound, interms of disk access, and this is usually the determining factor in message latency, so adding the statistics counters places no large additional burden, and will not add a large amount to the latency, certainly less that 5% degradation. It is obvious that <b>any</b> additional processing that talkes place during the act of delivery or receipt of a message will inevitably add latency and decrease throughput on the broker. If a broker is already operati ng at peak performance, something that is only possible with transient messages, which are only dependant on the amount of CPU and RAM available, then the enabling of statistics counters will have a greater effect, possibly degrading pewrformance by over 10%.</p>

<h1><a name="QpidJavaBrokerStatistics-Tasks"></a>Tasks</h1>

<ul>
	<li>Create generic data capture utility for gathering stats on received/delivered messages inc current/peak messages/sec and rolling total messages inc message count and bytes (payload only) stats, inc unit tests. Requires further discussion.</li>
	<li>Configure stats capture (on/off) for broker (config.xml - new section) and per connection (jmx) and data extract dump interval, and code to dump stats data</li>
	<li>Expose stats via JMX MBean attributes for query by users (<cite>notification</cite> - reqs to be confirmed with client), add reset feature via JMX and tests for these features. JMX changes to expose new stats attributes and reset function, inc tests</li>
	<li>Performance test to measure overhead of stats calculation (see RG email/example class) - separate from perf test harness, small class to measure calc cost only</li>
</ul>


<p><a href="https://issues.apache.org/jira/browse/QPID-2932" class="external-link" rel="nofollow">QPID-2932</a> Add statistics generation for broker message delivery<br/>
<a href="https://issues.apache.org/jira/browse/QPID-????" class="external-link" rel="nofollow">QPID-????</a> Port to trunk</p>
    </div>
    <div id="commentsSection" class="wiki-content pageSection">
       <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action" class="grey">Change Notification Preferences</a>
       </div>
       <a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Broker+Statistics">View Online</a>
              |
       <a href="https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Broker+Statistics?showComments=true&amp;showCommentArea=true#addcomment">Add Comment</a>
           </div>
</div>
</div>
</div>
</div>
</body>
</html>

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:commits-subscribe@qpid.apache.org


Mime
View raw message