Sorry for being late here Yu Li.
Regarding counting the rows (for the new metric) in multi..  There
might be 2 Actions in multi request for the same row. This is possible
some time.  I dont think we should check that and try to make it
perfect. That will have perf penalty also.  So just saying that we
will have some possible inconsistency even after.  May be we can say
how many actions in multi not rows affected!  any better name ?

On Mon, Aug 7, 2017 at 8:07 AM, Yu Li <car...@gmail.com> wrote:
> Thanks for chiming in @stack and @Jerry, will try to add a good release
> note when the work done.
>
> Since already more than 72 hours passed and no objections, I'd like to call
> this discussion closed and apply the change in HBASE-18469. Thanks.
>
> Best Regards,
> Yu
>
> On 4 August 2017 at 13:59, stack <saint....@gmail.com> wrote:
>
>> +1
>>
>> We need a fat release note on this change so operators can quickly learn
>> why traffic went down on upgrade.
>>
>> S
>>
>> On Aug 3, 2017 14:49, "Yu Li" <car...@gmail.com> wrote:
>>
>> > Dear all,
>> >
>> > Recently in HBASE-18469 <https://issues.apache.org/
>> jira/browse/HBASE-18469
>> > >
>> > we found some inconsistency on regionserver request related metrics,
>> > including:
>> > 1. totalRequestCount could be less than readRequestCount+
>> writeRequestCount
>> > 2. For multi request, we count action count into totalRequestCount, while
>> > for scan with caching we count only one.
>> >
>> > To fix the inconsistency, we plan to make below changes:
>> > 1. Make totalRequestCount only counts rpc request, thus multi request
>> will
>> > only count as one for totalRequestCount
>> > 2. Introduce a new metrics in name of "totalRowsRequestCount", which will
>> > count the DML workloads on RS by row-level action, and for this metrics
>> we
>> > will count how many rows included for multi and scan-with-caching
>> request.
>> >
>> > After the change, there won't be any compatibility issue -- existing
>> > monitoring system could still work -- only that totalRequestCount will be
>> > less than previous. And it's recommended to use totalRowsRequestCount to
>> > check the RS DML workload.
>> >
>> > Please kindly let us know if you have any different idea or suggestion
>> > (operators' opinion is especially welcomed).
>> >
>> > Let's make this discussion open for 72 hours and will make the change if
>> no
>> > objections.
>> >
>> > Thanks!
>> >
>> > Best Regards,
>> > Yu
>> >
>>

Reply via email to