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 <code>callQueue</code> 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. +