You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@phoenix.apache.org by ja...@apache.org on 2014/10/29 18:15:16 UTC
svn commit: r1635206 - in /phoenix/site: publish/tuning.html
source/src/site/markdown/tuning.md
Author: jamestaylor
Date: Wed Oct 29 17:15:15 2014
New Revision: 1635206
URL: http://svn.apache.org/r1635206
Log:
Update typos in tuning page
Modified:
phoenix/site/publish/tuning.html
phoenix/site/source/src/site/markdown/tuning.md
Modified: phoenix/site/publish/tuning.html
URL: http://svn.apache.org/viewvc/phoenix/site/publish/tuning.html?rev=1635206&r1=1635205&r2=1635206&view=diff
==============================================================================
--- phoenix/site/publish/tuning.html (original)
+++ phoenix/site/publish/tuning.html Wed Oct 29 17:15:15 2014
@@ -1,7 +1,7 @@
<!DOCTYPE html>
<!--
- Generated by Apache Maven Doxia at 2014-10-28
+ Generated by Apache Maven Doxia at 2014-10-29
Rendered using Reflow Maven Skin 1.1.0 (http://andriusvelykis.github.io/reflow-maven-skin)
-->
<html xml:lang="en" lang="en">
@@ -155,7 +155,7 @@
</tr>
<tr class="b">
<td><small>phoenix.stats.guidepost.width</small></td>
- <td> A server-side parameter that specifies the number of bytes between guideposts. A smaller amount increases parallelization, but also increases the number of chunks which must be merged on the client side. The default value is 10 MB. </td>
+ <td> A server-side parameter that specifies the number of bytes between guideposts. A smaller amount increases parallelization, but also increases the number of chunks which must be merged on the client side. The default value is 100 MB. </td>
<td>104857600</td>
</tr>
<tr class="a">
@@ -324,6 +324,11 @@
<td>300000</td>
</tr>
<tr class="b">
+ <td><small>phoenix.query.rowKeyOrderSaltedTable</small></td>
+ <td style="text-align: left;">Whether or not a non aggregate query returns rows in row key order for salted tables. If this option is turned on, split points may not be specified at table create time, but instead the default splits on each salt bucket must be used. Default is true</td>
+ <td>true</td>
+ </tr>
+ <tr class="a">
<td><small>
<s>
phoenix.query.targetConcurrency
@@ -331,7 +336,7 @@
<td style="text-align: left;">Target concurrent threads to use for a query. It serves as a soft limit on the number of scans into which a query may be split. The value should not exceed the hard limit imposed by<tt> phoenix.query.maxConcurrency</tt>.</td>
<td>32</td>
</tr>
- <tr class="a">
+ <tr class="b">
<td><small>
<s>
phoenix.query.maxConcurrency
@@ -339,7 +344,7 @@
<td style="text-align: left;">Maximum concurrent threads to use for a query. It servers as a hard limit on the number of scans into which a query may be split. A soft limit is imposed by <tt>phoenix.query.targetConcurrency</tt>.</td>
<td>64</td>
</tr>
- <tr class="b">
+ <tr class="a">
<td><small>
<s>
phoenix.query.maxStatsAge
@@ -347,7 +352,7 @@
<td>The maximum age of stats in milliseconds after which they will no longer be used (i.e. the stats were not able to be updated in this amount of time and thus are considered too old). Default is 1 day.</td>
<td>1</td>
</tr>
- <tr class="a">
+ <tr class="b">
<td><small>
<s>
phoenix.query.statsUpdateFrequency
@@ -355,7 +360,7 @@
<td style="text-align: left;">The frequency in milliseconds at which the stats for each table will be updated. Default is 15 min.</td>
<td>900000</td>
</tr>
- <tr class="b">
+ <tr class="a">
<td><small>
<s>
phoenix.query.maxIntraRegionParallelization
@@ -363,20 +368,15 @@
<td style="text-align: left;">The maximum number of threads that will be spawned to process data within a single region during query execution</td>
<td>64</td>
</tr>
- <tr class="a">
- <td><small>phoenix.query.rowKeyOrderSaltedTable</small></td>
- <td style="text-align: left;">Whether or not a non aggregate query returns rows in row key order for salted tables. If this option is turned on, split points may not be specified at table create time, but instead the default splits on each salt bucket must be used. Default is true</td>
- <td>true</td>
- </tr>
</tbody>
</table>
<br />
<div class="section">
<div class="section">
<div class="section">
- <h4 id="Parallelization"> Parallelization</h4> Phoenix breaks up aggregate queries into multiple scans and runs them in parallel through custom aggregating coprocessors to improve performance. Hari Kumar, from Ericsson Labs, did a good job of explaining the performance benefits of parallelization and coprocessors
- <a class="externalLink" href="http://labs.ericsson.com/blog/hbase-performance-tuners" target="_blank">here</a>.
- <p>As of 3.2/4.2, parallelization in Phoenix is driven by the guideposts as determined by the configuration parameters for <a class="externalLink" href="http://phoenix.apache.org/update_statistics.html">statistics collection</a>. Each chunk of data between guideposts will be run in parallel in a separate scan to improve query performance. Note that at a minimum, separate scans will be run for each table region. Beyond the statistics collection configuration parameters, the client-side <tt>phoenix.query.threadPoolSize</tt> and <tt>phoenix.query.queueSize</tt> parameters and the server-side <tt>hbase.regionserver.handler.count</tt> parameter have an impact on performance.</p>
+ <h4 id="Parallelization"> Parallelization</h4>
+ <p>Phoenix breaks up queries into multiple scans and runs them in parallel through coprocessors to improve performance. Hari Kumar, from Ericsson Labs, did a good job of explaining the performance benefits of parallelization and coprocessors <a class="externalLink" href="http://labs.ericsson.com/blog/hbase-performance-tuners" target="_blank">here</a>.</p>
+ <p>As of 3.2/4.2, parallelization in Phoenix is driven by the guideposts as determined by the configuration parameters for [statistics collection](http://phoenix.apache.org/update_statistics.html). Each chunk of data between guideposts will be run in parallel in a separate scan to improve query performance. The chunk size is determined by the server-side <tt>phoenix.stats.guidepost.width</tt> or <tt>phoenix.stats.guidepost.per.region</tt> configuration parameters. Note that at a minimum, separate scans will be run for each table region. Beyond the statistics collection configuration parameters, the client-side <tt>phoenix.query.threadPoolSize</tt> and <tt>phoenix.query.queueSize</tt> parameters and the server-side <tt>hbase.regionserver.handler.count</tt> parameter have an impact on performance.</p>
</div>
</div>
</div>
Modified: phoenix/site/source/src/site/markdown/tuning.md
URL: http://svn.apache.org/viewvc/phoenix/site/source/src/site/markdown/tuning.md?rev=1635206&r1=1635205&r2=1635206&view=diff
==============================================================================
--- phoenix/site/source/src/site/markdown/tuning.md (original)
+++ phoenix/site/source/src/site/markdown/tuning.md Wed Oct 29 17:15:15 2014
@@ -29,7 +29,7 @@ of the
<tr><td><small>phoenix.stats.guidepost.width</small></td><td>
A server-side parameter that specifies the number of bytes between guideposts.
A smaller amount increases parallelization, but also increases the number of
- chunks which must be merged on the client side. The default value is 10 MB.
+ chunks which must be merged on the client side. The default value is 100 MB.
</td><td>104857600</td></tr>
<tr><td><small>phoenix.stats.guidepost.per.region</small></td><td>
A server-side parameter that specifies the number of guideposts per region.
@@ -129,6 +129,7 @@ overridden at connection
</td><td>10000</td></tr>
<tr><td><small>phoenix.index.failure.handling.rebuild.overlap.time</small></td><td style="text-align: left;">Index rebuild job builds an index from when it failed - the time interval(in milliseconds) in order to create a time overlap to prevent missing updates when there exists time clock skew.
</td><td>300000</td></tr>
+<tr><td><small>phoenix.query.rowKeyOrderSaltedTable</small></td><td style="text-align: left;">Whether or not a non aggregate query returns rows in row key order for salted tables. If this option is turned on, split points may not be specified at table create time, but instead the default splits on each salt bucket must be used. Default is true</td><td>true</td></tr>
<tr><td><strike><small>phoenix.query.targetConcurrency</small></strike><br/>Obsolete as of 3.2/4.2</td><td style="text-align: left;">Target concurrent
threads to use for a query. It serves as a soft limit on the number of
scans into which a query may be split. The value should not exceed the hard limit imposed by<code> phoenix.query.maxConcurrency</code>.</td><td>32</td></tr>
@@ -142,17 +143,18 @@ overridden at connection
in milliseconds at which the stats for each table will be
updated. Default is 15 min.</td><td>900000</td></tr>
<tr><td><strike><small>phoenix.query.maxIntraRegionParallelization</small></strike><br/>Obsolete as of 3.2/4.2</td><td style="text-align: left;">The maximum number of threads that will be spawned to process data within a single region during query execution</td><td>64</td></tr>
-<tr><td><small>phoenix.query.rowKeyOrderSaltedTable</small></td><td style="text-align: left;">Whether or not a non aggregate query returns rows in row key order for salted tables. If this option is turned on, split points may not be specified at table create time, but instead the default splits on each salt bucket must be used. Default is true</td><td>true</td></tr>
</tbody></table>
<br />
<h4>
Parallelization</h4>
-Phoenix breaks up aggregate queries into multiple scans and runs them in parallel through custom aggregating coprocessors to improve performance. Hari Kumar, from Ericsson Labs, did a good job of explaining the performance benefits of parallelization and coprocessors <a href="http://labs.ericsson.com/blog/hbase-performance-tuners" target="_blank">here</a>.
+<p>Phoenix breaks up queries into multiple scans and runs them in parallel through coprocessors to improve performance. Hari Kumar, from Ericsson Labs, did a good job of explaining the performance benefits of parallelization and coprocessors <a href="http://labs.ericsson.com/blog/hbase-performance-tuners" target="_blank">here</a>.</p>
-As of 3.2/4.2, parallelization in Phoenix is driven by the guideposts as determined by the configuration parameters for
-[statistics collection](http://phoenix.apache.org/update_statistics.html). Each chunk of data between guideposts
-will be run in parallel in a separate scan to improve query performance. Note that at a minimum, separate scans will be
-run for each table region. Beyond the statistics collection configuration parameters, the client-side
-<code>phoenix.query.threadPoolSize</code> and <code>phoenix.query.queueSize</code> parameters and the server-side
-<code>hbase.regionserver.handler.count</code> parameter have an impact on performance.
+<p>As of 3.2/4.2, parallelization in Phoenix is driven by the guideposts as determined by the configuration
+parameters for [statistics collection](http://phoenix.apache.org/update_statistics.html). Each chunk of data
+between guideposts will be run in parallel in a separate scan to improve query performance. The chunk size
+is determined by the server-side <code>phoenix.stats.guidepost.width</code> or
+<code>phoenix.stats.guidepost.per.region</code> configuration parameters. Note that at a minimum, separate
+scans will be run for each table region. Beyond the statistics collection configuration parameters,
+the client-side <code>phoenix.query.threadPoolSize</code> and <code>phoenix.query.queueSize</code> parameters
+and the server-side <code>hbase.regionserver.handler.count</code> parameter have an impact on performance.</p>