Re: [DISCUSS] Planning changes on RegionServer totalRequestCount metrics

[Anoop John]

I see..  Good...  Ya +1

On Tue, Aug 8, 2017 at 8:46 AM, Yu Li  wrote:
> Thanks for chiming in @Anoop. Jerry raised the same question in JIRA and
> the patch is already updated there, will rename the metrics to
> "totalRowActionRequestCount". Will add release note to make it clear for
> user what the final changes are
>
> Best Regards,
> Yu
>
> On 7 August 2017 at 15:19, Anoop John  wrote:
>
>> 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  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  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"  wrote:
>> >>
>> >> > Dear all,
>> >> >
>> >> > Recently in HBASE-18469 > >> 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
>> >> >
>> >>
>>

Re: [DISCUSS] Planning changes on RegionServer totalRequestCount metrics

[Yu Li]

Thanks for chiming in @Anoop. Jerry raised the same question in JIRA and
the patch is already updated there, will rename the metrics to
"totalRowActionRequestCount". Will add release note to make it clear for
user what the final changes are

Best Regards,
Yu

On 7 August 2017 at 15:19, Anoop John  wrote:

> 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  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  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"  wrote:
> >>
> >> > Dear all,
> >> >
> >> > Recently in HBASE-18469  >> 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
> >> >
> >>
>

Re: [DISCUSS] Planning changes on RegionServer totalRequestCount metrics

[Anoop John]

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  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  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"  wrote:
>>
>> > Dear all,
>> >
>> > Recently in HBASE-18469 > 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
>> >
>>

Re: [DISCUSS] Planning changes on RegionServer totalRequestCount metrics

[Yu Li]

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  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"  wrote:
>
> > Dear all,
> >
> > Recently in HBASE-18469  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
> >
>

Re: [DISCUSS] Planning changes on RegionServer totalRequestCount metrics

[stack]

+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"  wrote:

> Dear all,
>
> Recently in 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
>

Re: [DISCUSS] Planning changes on RegionServer totalRequestCount metrics

[Jerry He]

I like the ideal to clean it up and make it clear.  I had the same
confusion as well.
Will look at the JIRA and comment there as well.

Thanks.

Jerry

On Wed, Aug 2, 2017 at 11:48 PM, Yu Li  wrote:
> Dear all,
>
> Recently in 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