diff --git src/main/docbkx/performance.xml src/main/docbkx/performance.xml
index 57c866a..15a370f 100644
--- src/main/docbkx/performance.xml
+++ src/main/docbkx/performance.xml
@@ -254,7 +254,130 @@
release note on HBASE-5074 support checksums in HBase block cache.
-
+
+ Tuning callQueue Options
+ HBASE-11355
+ introduces several callQueue tuning mechanisms which can increase performance. See the JIRA
+ for some benchmarking information.
+
+
+ To increase the number of callqueues, set
+ to a value greater than
+ 1.
+
+
+ To split the callqueue into separate read and write queues, set
+ hbase.ipc.server.callqueue.read.ratio to a value between
+ 0 and 1. This factor weights the queues toward
+ reads (if below .5) or writes (if above .5). The following examples illustrate some of
+ the possibilities. Note that you always have at least one write queue, no matter what
+ setting you use.
+
+
+ The default value of 0 does not split the queue.
+
+
+ A value of .3 uses 30% of the queues for reading and 60% for
+ writing. Given a value of 10 for
+ , 3 queues would be used for reads
+ and 7 for writes.
+
+
+ A value of .5 uses the same number of read queues and write
+ queues. Given a value of 10 for
+ , 5 queues would be used for reads
+ and 5 for writes.
+
+
+ A value of .6 uses 75% of the queues for writing and 25% for
+ reading. Given a value of 10 for
+ , 7 queues would be used for reads
+ and 3 for writes.
+
+
+ A value of 1.0 uses one queue to process write requests, and
+ all other queues process read requests. A value higher than 1.0
+ has the same effect as a value of 1.0. Given a value of
+ 10 for , 9
+ queues would be used for reads and 1 for writes.
+
+
+
+
+ You can also split the read queues so that separate queues are used for short reads
+ (from Get operations) and short reads (from Scan operations), by setting the
+ option. This option is a factor
+ between 0 and 1, which determine the ratio of read queues used for Gets and Scans. More
+ queues are used for Gets if the value is below .5 and more are used
+ for scans if the value is above .5. No matter what setting you use,
+ at least one read queue is used for Get operations.
+
+
+ A value of 0 does not split the read queue.
+
+
+ A value of .3 uses 60% of the read queues for Gets and 30%
+ for Scans. Given a value of 20 for
+ and a value of .5
+ for , 10 queues
+ would be used for reads, out of those 10, 7 would be used for Gets and 3 for
+ Scans.
+
+
+ A value of .5 uses half the read queues for Gets and half for
+ Scans. Given a value of 20 for
+ and a value of .5
+ for , 10 queues
+ would be used for reads, out of those 10, 5 would be used for Gets and 5 for
+ Scans.
+
+
+ A value of .6 uses 30% of the read queues for Gets and 60%
+ for Scans. Given a value of 20 for
+ and a value of .5
+ for , 10 queues
+ would be used for reads, out of those 10, 3 would be used for Gets and 7 for
+ Scans.
+
+
+ A value of 1.0 uses all but one of the read queues for Scans.
+ Given a value of 20 for
+ and a value of .5
+ for , 10 queues
+ would be used for reads, out of those 10, 1 would be used for Gets and 9 for
+ Scans.
+
+
+
+
+ You can use the new option
+ to programmatically tune
+ the number of queues:
+
+
+ A value of 0 uses a single shared queue between all the
+ handlers.
+
+
+ A value of 1 uses a separate queue for each handler.
+
+
+ A value between 0 and 1 tunes the number
+ of queues against the number of handlers. For instance, a value of
+ .5 shares one queue between each two handlers.
+
+
+ Having more queues, such as in a situation where you have one queue per handler,
+ reduces contention when adding a task to a queue or selecting it from a queue. The
+ trade-off is that if you have some queues with long-running tasks, a handler may end up
+ waiting to execute from that queue rather than processing another queue which has
+ waiting tasks.
+
+
+ For these values to take effect on a given Region Server, the Region Server must be
+ restarted. These parameters are intended for testing purposes and should be used
+ carefully.
+