[
https://issues.apache.org/jira/browse/HBASE-13521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14504482#comment-14504482
]
Elliott Clark commented on HBASE-13521:
---------------------------------------
There's already a gets metric (taken from /jmx on a regionserver):
{code}
Get_num_ops: 673,
Get_min: 0,
Get_max: 9,
Get_mean: 0.22585438335809807,
Get_median: 0,
Get_75th_percentile: 0,
Get_95th_percentile: 1,
Get_99th_percentile: 1,
{code}
Get_num_ops will be how many gets are received. the
min/max/median/75th,95th,99th refer to time taken to respond to a get request.
These metrics are available per server and per region.
> Create metric for get requests
> ------------------------------
>
> Key: HBASE-13521
> URL: https://issues.apache.org/jira/browse/HBASE-13521
> Project: HBase
> Issue Type: Improvement
> Components: metrics, regionserver
> Affects Versions: 1.0.0
> Reporter: cuijianwei
> Priority: Minor
>
> Currently, the readRequestsCount records the request count for both get
> request(random read) and scan#next request(sequential read). However, the
> cost of get request and scan#next request are different, and usually the get
> request is much more heavy than the scan#next. Is it reasonable to create a
> metric getRequestsCount to record the get request count specifically? Then,
> we can trigger an alert if getRequestsCount grows too fast because large
> number of random read requests will cause cluster overload more easily(The
> readRequestsCount will easily grow fast if there is a scan, however, this may
> not cause the system overload because sequential read is much more fast).
> Discussions and suggestions are welcomed! Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
