HBase
  1. HBase
  2. HBASE-6377

HBASE-5533 metrics miss all operations submitted via MultiAction

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.94.1, 0.95.2
    • Fix Version/s: 0.94.1, 0.95.0
    • Component/s: metrics, regionserver
    • Labels:
      None
    • Hadoop Flags:
      Reviewed
    • Release Note:
      The misleading "getRequestLatency", "deleteRequestLatency", and "putRequestLatency" histograms were removed from metrics because such requests often were not actually measured.

      Description

      A client application (LoadTestTool) calls put() on HTables. Internally to the HBase client those puts are batched into MultiActions. The total number of put operations shown in the RegionServer's put metrics histogram never increases from 0 even though millions of such operations are made. Needless to say the latency for those operations are not measured either. The value of HBASE-5533 metrics are suspect given the client will batch put and delete ops like this.

      I had a fix in progress but HBASE-6284 messed it up. Before, MultiAction processing in HRegionServer would distingush between puts and deletes and dispatch them separately. It was easy to account for the time for them. Now both puts and deletes are submitted in batch together as mutations.

      1. 6377-trunk-remove-get-put-delete-histograms.patch
        3 kB
        Andrew Purtell
      2. 6377-0.94-remove-get-put-delete-histograms.patch
        5 kB
        Andrew Purtell
      3. 6377-0.94.patch
        20 kB
        Andrew Purtell
      4. 6377.patch
        10 kB
        Andrew Purtell
      5. 6377-trunk-simple.patch
        7 kB
        Andrew Purtell
      There are no Sub-Tasks for this issue.

        Activity

        Hide
        Misty Stanley-Jones added a comment -

        Wrong ticket, sorry.

        Show
        Misty Stanley-Jones added a comment - Wrong ticket, sorry.
        Hide
        Misty Stanley-Jones added a comment -

        Thanks, I will work something up. This is very helpful.

        Show
        Misty Stanley-Jones added a comment - Thanks, I will work something up. This is very helpful.
        Lars Hofhansl made changes -
        Fix Version/s 0.94.2 [ 12321884 ]
        Fix Version/s 0.94.1 [ 12320257 ]
        Lars Hofhansl made changes -
        Fix Version/s 0.94.2 [ 12321884 ]
        stack made changes -
        Fix Version/s 0.95.0 [ 12324094 ]
        Fix Version/s 0.96.0 [ 12320040 ]
        Fix Version/s 0.94.1 [ 12320257 ]
        Lars Hofhansl made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Hudson added a comment -

        Integrated in HBase-0.94-security-on-Hadoop-23 #6 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/6/)
        HBASE-6377. HBASE-5533 metrics miss all operations submitted via MultiAction

        Applied 6377-0.94-remove-get-put-delete-histograms.patch (Revision 1361028)

        Result = FAILURE
        apurtell :
        Files :

        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
        Show
        Hudson added a comment - Integrated in HBase-0.94-security-on-Hadoop-23 #6 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/6/ ) HBASE-6377 . HBASE-5533 metrics miss all operations submitted via MultiAction Applied 6377-0.94-remove-get-put-delete-histograms.patch (Revision 1361028) Result = FAILURE apurtell : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
        Hide
        Hudson added a comment -

        Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #92 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/92/)
        HBASE-6377. HBASE-5533 metrics miss all operations submitted via MultiAction

        Committed 6377-trunk-remove-get-put-delete-histograms.patch (Revision 1361026)

        Result = FAILURE
        apurtell :
        Files :

        • /hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/ServerMetricsTmpl.jamon
        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
        Show
        Hudson added a comment - Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #92 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/92/ ) HBASE-6377 . HBASE-5533 metrics miss all operations submitted via MultiAction Committed 6377-trunk-remove-get-put-delete-histograms.patch (Revision 1361026) Result = FAILURE apurtell : Files : /hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/ServerMetricsTmpl.jamon /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
        Hide
        Hudson added a comment -

        Integrated in HBase-TRUNK #3122 (See https://builds.apache.org/job/HBase-TRUNK/3122/)
        HBASE-6377. HBASE-5533 metrics miss all operations submitted via MultiAction

        Committed 6377-trunk-remove-get-put-delete-histograms.patch (Revision 1361026)

        Result = FAILURE
        apurtell :
        Files :

        • /hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/ServerMetricsTmpl.jamon
        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
        Show
        Hudson added a comment - Integrated in HBase-TRUNK #3122 (See https://builds.apache.org/job/HBase-TRUNK/3122/ ) HBASE-6377 . HBASE-5533 metrics miss all operations submitted via MultiAction Committed 6377-trunk-remove-get-put-delete-histograms.patch (Revision 1361026) Result = FAILURE apurtell : Files : /hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/ServerMetricsTmpl.jamon /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
        Hide
        Hudson added a comment -

        Integrated in HBase-0.94 #313 (See https://builds.apache.org/job/HBase-0.94/313/)
        HBASE-6377. HBASE-5533 metrics miss all operations submitted via MultiAction

        Applied 6377-0.94-remove-get-put-delete-histograms.patch (Revision 1361028)

        Result = FAILURE
        apurtell :
        Files :

        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
        Show
        Hudson added a comment - Integrated in HBase-0.94 #313 (See https://builds.apache.org/job/HBase-0.94/313/ ) HBASE-6377 . HBASE-5533 metrics miss all operations submitted via MultiAction Applied 6377-0.94-remove-get-put-delete-histograms.patch (Revision 1361028) Result = FAILURE apurtell : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
        Hide
        Hudson added a comment -

        Integrated in HBase-0.94-security #40 (See https://builds.apache.org/job/HBase-0.94-security/40/)
        HBASE-6377. HBASE-5533 metrics miss all operations submitted via MultiAction

        Applied 6377-0.94-remove-get-put-delete-histograms.patch (Revision 1361028)

        Result = SUCCESS
        apurtell :
        Files :

        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
        Show
        Hudson added a comment - Integrated in HBase-0.94-security #40 (See https://builds.apache.org/job/HBase-0.94-security/40/ ) HBASE-6377 . HBASE-5533 metrics miss all operations submitted via MultiAction Applied 6377-0.94-remove-get-put-delete-histograms.patch (Revision 1361028) Result = SUCCESS apurtell : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java
        Andrew Purtell made changes -
        Release Note The misleading "getRequestLatency", "deleteRequestLatency", and "putRequestLatency" histograms were removed from metrics because such requests often were not actually measured.
        Fix Version/s 0.96.0 [ 12320040 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Hadoop Flags Reviewed [ 10343 ]
        Resolution Fixed [ 1 ]
        Hide
        Andrew Purtell added a comment -

        I committed the "remove-get-put-delete-histograms" patches to trunk and 0.94 branch. Thanks everyone for the feedback.

        Show
        Andrew Purtell added a comment - I committed the "remove-get-put-delete-histograms" patches to trunk and 0.94 branch. Thanks everyone for the feedback.
        Hide
        Elliott Clark added a comment -

        @Andrew
        They're exposed through jmx too. All the more reason to get them correct if we're going to do them.

        +1 on trunk patch. After 4050 goes in I'm going to try and get to some of the metric re-writes that are needed. Looks like this will be one on the list.

        Show
        Elliott Clark added a comment - @Andrew They're exposed through jmx too. All the more reason to get them correct if we're going to do them. +1 on trunk patch. After 4050 goes in I'm going to try and get to some of the metric re-writes that are needed. Looks like this will be one on the list.
        Andrew Purtell made changes -
        Hide
        Andrew Purtell added a comment -

        Attached similar "remove" patch for trunk.

        Show
        Andrew Purtell added a comment - Attached similar "remove" patch for trunk.
        Hide
        Andrew Purtell added a comment - - edited

        @Elliot we should do the same on trunk and fix up the UI.

        Edit: Currently the only place those histograms are referenced are the Jamon templates.

        Show
        Andrew Purtell added a comment - - edited @Elliot we should do the same on trunk and fix up the UI. Edit: Currently the only place those histograms are referenced are the Jamon templates.
        Hide
        Elliott Clark added a comment -

        Looks good to me. That was fast. Thanks

        Show
        Elliott Clark added a comment - Looks good to me. That was fast. Thanks
        Hide
        Lars Hofhansl added a comment -

        +1 on the "remove-get-put-delete-histograms" patch

        Show
        Lars Hofhansl added a comment - +1 on the "remove-get-put-delete-histograms" patch
        Lars Hofhansl made changes -
        Fix Version/s 0.94.1 [ 12320257 ]
        Fix Version/s 0.94.2 [ 12321884 ]
        Hide
        Andrew Purtell added a comment -

        Attached. You can also disregard the trunk patch on this issue if not attempting to preserve the old stuff.

        Show
        Andrew Purtell added a comment - Attached. You can also disregard the trunk patch on this issue if not attempting to preserve the old stuff.
        Andrew Purtell made changes -
        Hide
        Andrew Purtell added a comment -

        Putting up a 0.94 patch that pulls the dodgy metrics in a few minutes.

        Show
        Andrew Purtell added a comment - Putting up a 0.94 patch that pulls the dodgy metrics in a few minutes.
        Hide
        Elliott Clark added a comment -

        That would be my vote for 0.94 at least.

        Show
        Elliott Clark added a comment - That would be my vote for 0.94 at least.
        Hide
        Andrew Purtell added a comment -

        If you guys think this is not worth it, then we should yank it out.

        Show
        Andrew Purtell added a comment - If you guys think this is not worth it, then we should yank it out.
        Hide
        Andrew Purtell added a comment - - edited

        Again, the 0.94 patch just puts back HBASE-5533 style measurements, not reinventing proper accounting. Edit: I should say makes them not mostly useless.

        Show
        Andrew Purtell added a comment - - edited Again, the 0.94 patch just puts back HBASE-5533 style measurements, not reinventing proper accounting. Edit: I should say makes them not mostly useless.
        Hide
        Andrew Purtell added a comment -

        The histogram could be dominated by the bulk insert operation.

        If you mean Put(List) or MultiAction, each dispatch down to HRegion is individually accounted. A big limitation we have with this approach of measuring at HRI is we can't drop down into the region to account for each op individually. Current 0.94 patch maintains how the HBASE-5533 patch did it.

        I believe such issues of larger rethinking were what Lars had in mind in comments above. TBD.

        Show
        Andrew Purtell added a comment - The histogram could be dominated by the bulk insert operation. If you mean Put(List) or MultiAction, each dispatch down to HRegion is individually accounted. A big limitation we have with this approach of measuring at HRI is we can't drop down into the region to account for each op individually. Current 0.94 patch maintains how the HBASE-5533 patch did it. I believe such issues of larger rethinking were what Lars had in mind in comments above. TBD.
        Hide
        Andrew Wang added a comment -

        Please correct my understanding on this if I'm wrong, but estimating via the average (total latency / num ops) is pretty undesirable for both normal MultiActions and the batched put MultiAction case. Latency from a slow op bleeds over to a fast one, which messes up per-op metrics. This would also affect doing per-region or per-column family metrics in the future, for the same reasons.

        I haven't looked at the code, but is it possible to do more accurate accounting of the latency of each op in a MultiAction? If so, I think it'd be worthwhile.

        Show
        Andrew Wang added a comment - Please correct my understanding on this if I'm wrong, but estimating via the average (total latency / num ops) is pretty undesirable for both normal MultiActions and the batched put MultiAction case. Latency from a slow op bleeds over to a fast one, which messes up per-op metrics. This would also affect doing per-region or per-column family metrics in the future, for the same reasons. I haven't looked at the code, but is it possible to do more accurate accounting of the latency of each op in a MultiAction? If so, I think it'd be worthwhile.
        Hide
        Elliott Clark added a comment -

        The trunk patch looks great.
        The 0.94 patch, Will give some really weird numbers I think. The histogram could be dominated by the bulk insert operation. Should that be switched to just a PersistantTimeVaryingRate? Better to give less information, but for it to be accurate.

        Show
        Elliott Clark added a comment - The trunk patch looks great. The 0.94 patch, Will give some really weird numbers I think. The histogram could be dominated by the bulk insert operation. Should that be switched to just a PersistantTimeVaryingRate? Better to give less information, but for it to be accurate.
        Hide
        Andrew Purtell added a comment -

        Tangentially, if we're doing all over the place a lot of this get nanos then get them again and subtract the diff, we might want to just use Guava's Stopwatch. Also, in our internal version of 0.94 we've scaled metrics to milliseconds. The Stopwatch javadocs talk about that: "Note that the overhead of measurement can be more than a microsecond, so it is generally not useful to specify TimeUnit.NANOSECONDS precision here." For another JIRA perhaps.

        Show
        Andrew Purtell added a comment - Tangentially, if we're doing all over the place a lot of this get nanos then get them again and subtract the diff, we might want to just use Guava's Stopwatch. Also, in our internal version of 0.94 we've scaled metrics to milliseconds. The Stopwatch javadocs talk about that: "Note that the overhead of measurement can be more than a microsecond, so it is generally not useful to specify TimeUnit.NANOSECONDS precision here." For another JIRA perhaps.
        Hide
        stack added a comment -

        If its wonky, it goes w/o saying that you didn't do it. But yeah, wonky. Patch seems fine to me.

        Show
        stack added a comment - If its wonky, it goes w/o saying that you didn't do it. But yeah, wonky. Patch seems fine to me.
        Hide
        Andrew Purtell added a comment -

        But, as before, for N ops you have to submit (totalTime/N) N times to the histogram.

        That seems wonky Mr Purtell?

        Not my doing Mr. Stack, it's a histogram implementation detail.

        Show
        Andrew Purtell added a comment - But, as before, for N ops you have to submit (totalTime/N) N times to the histogram. That seems wonky Mr Purtell? Not my doing Mr. Stack, it's a histogram implementation detail.
        Andrew Purtell made changes -
        Attachment 6377.patch [ 12536285 ]
        Attachment 6377-0.94.patch [ 12536286 ]
        Hide
        Andrew Purtell added a comment -

        Attached are candidates for trunk and 0.94 currently under test. The 0.94 version is noisier than I'd prefer but it fills in where we were missing coverage before.

        Show
        Andrew Purtell added a comment - Attached are candidates for trunk and 0.94 currently under test. The 0.94 version is noisier than I'd prefer but it fills in where we were missing coverage before.
        Hide
        stack added a comment -

        Doing that. But, as before, for N ops you have to submit (totalTime/N) N times to the histogram.

        That seems wonky Mr Purtell?

        Patch seems fine to me.

        Mr Elliott, you have carnal knowledge of metrics, any opinion?

        Show
        stack added a comment - Doing that. But, as before, for N ops you have to submit (totalTime/N) N times to the histogram. That seems wonky Mr Purtell? Patch seems fine to me. Mr Elliott, you have carnal knowledge of metrics, any opinion?
        Hide
        Andrew Purtell added a comment -

        We can report per op latency just by dividing the batch latency by the batch size

        Doing that. But, as before, for N ops you have to submit (totalTime/N) N times to the histogram.

        Show
        Andrew Purtell added a comment - We can report per op latency just by dividing the batch latency by the batch size Doing that. But, as before, for N ops you have to submit (totalTime/N) N times to the histogram.
        Hide
        Lars Hofhansl added a comment -

        I think approach is good, though. Let's just do your patch and then regroup

        Show
        Lars Hofhansl added a comment - I think approach is good, though. Let's just do your patch and then regroup
        Hide
        Lars Hofhansl added a comment - - edited

        Looks good to me. Reasoning makes sense.
        We can report per op latency just by dividing the batch latency by the batch size (still no need to deconstruct per individual op). Not sure if that more useful or less.

        Does this need more discussion? If so, maybe the best course of action is to revert HBASE-5533 now and regroup.

        Show
        Lars Hofhansl added a comment - - edited Looks good to me. Reasoning makes sense. We can report per op latency just by dividing the batch latency by the batch size (still no need to deconstruct per individual op). Not sure if that more useful or less. Does this need more discussion? If so, maybe the best course of action is to revert HBASE-5533 now and regroup.
        Hide
        Andrew Purtell added a comment -

        Let me know if you want me to proceed with this approach; I'll backport to 0.94 and commit trunk and 0.94 branch.

        Show
        Andrew Purtell added a comment - Let me know if you want me to proceed with this approach; I'll backport to 0.94 and commit trunk and 0.94 branch.
        Andrew Purtell made changes -
        Attachment 6377-trunk-simple.patch [ 12536256 ]
        Hide
        Andrew Purtell added a comment -

        Actually attach the correct diff.

        Show
        Andrew Purtell added a comment - Actually attach the correct diff.
        Andrew Purtell made changes -
        Attachment 6377-trunk-simple.patch [ 12536255 ]
        Andrew Purtell made changes -
        Assignee Andrew Purtell [ apurtell ]
        Andrew Purtell made changes -
        Attachment 6377-trunk-simple.patch [ 12536255 ]
        Hide
        Andrew Purtell added a comment -

        Attached as '6377-trunk-simple.patch' for your consideration is a minimal set of changes that put back HRegionInterface level request metrics. The intent of HBASE-5533 was to have server side request metrics to match up with client side metrics. So what we are measuring here? Here is my interpretation: Given all of the batching/dispatch/increasingly async actions taken by the client a 1:1 correspondence with client API ops is not what we are after; instead, a measure of the server side time required to process a unit of work sent by the client. This kind of measurement can be done simply and cheaply, especially given the nice HRI refactor in trunk. There's no need to ask "how to deconstruct this server side packet of work into client side ops and account for them individually?" On the other hand, it's a very coarse measurement.

        Show
        Andrew Purtell added a comment - Attached as '6377-trunk-simple.patch' for your consideration is a minimal set of changes that put back HRegionInterface level request metrics. The intent of HBASE-5533 was to have server side request metrics to match up with client side metrics. So what we are measuring here? Here is my interpretation: Given all of the batching/dispatch/increasingly async actions taken by the client a 1:1 correspondence with client API ops is not what we are after; instead, a measure of the server side time required to process a unit of work sent by the client. This kind of measurement can be done simply and cheaply, especially given the nice HRI refactor in trunk. There's no need to ask "how to deconstruct this server side packet of work into client side ops and account for them individually?" On the other hand, it's a very coarse measurement.
        Hide
        Andrew Purtell added a comment -

        On trunk apparently all use of the "get", "put", and "delete" histograms have already been removed from the regionserver, except for the Jamon templates. Since an approach to put back two such HRegionInterface level measurements with a query/mutate distinction has been +1ed on this issue I'm going to put them back on trunk and port back the changes to 0.94. Calling them queryRequestLatency and mutateRequestLatency in RegionServerMetrics.

        Show
        Andrew Purtell added a comment - On trunk apparently all use of the "get", "put", and "delete" histograms have already been removed from the regionserver, except for the Jamon templates. Since an approach to put back two such HRegionInterface level measurements with a query/mutate distinction has been +1ed on this issue I'm going to put them back on trunk and port back the changes to 0.94. Calling them queryRequestLatency and mutateRequestLatency in RegionServerMetrics.
        Hide
        Andrew Purtell added a comment -

        Will put something up today.

        Show
        Andrew Purtell added a comment - Will put something up today.
        Hide
        Lars Hofhansl added a comment -

        +1 on such a patch Andy, if you have bandwidth. (Would need to be quick to go into 0.94.1...)

        Show
        Lars Hofhansl added a comment - +1 on such a patch Andy, if you have bandwidth. (Would need to be quick to go into 0.94.1...)
        Lars Hofhansl made changes -
        Fix Version/s 0.94.2 [ 12321884 ]
        Hide
        Lars Hofhansl added a comment -

        IMHO misleading metrics are worse than no metrics, so I could see this in 0.94.1 as well.

        Show
        Lars Hofhansl added a comment - IMHO misleading metrics are worse than no metrics, so I could see this in 0.94.1 as well.
        Hide
        Andrew Purtell added a comment -

        Perhaps we can have "Get" and "Update" metrics. "Updates" would include Put, Deleted, ICV, etc

        I can supply a patch that does that. ?

        Show
        Andrew Purtell added a comment - Perhaps we can have "Get" and "Update" metrics. "Updates" would include Put, Deleted, ICV, etc I can supply a patch that does that. ?
        Hide
        stack added a comment -

        Let me know and I'll revert hbase-5533 (the patch that keeps on giving!)

        Show
        stack added a comment - Let me know and I'll revert hbase-5533 (the patch that keeps on giving!)
        Hide
        Lars Hofhansl added a comment -

        Perhaps we can have "Get" and "Update" metrics. "Updates" would include Put, Deleted, ICV, etc.
        But maybe that would require more discussion, so short term (0.94.1 at least), we could remove the Put/Delete/Get metrics as you suggest.

        Show
        Lars Hofhansl added a comment - Perhaps we can have "Get" and "Update" metrics. "Updates" would include Put, Deleted, ICV, etc. But maybe that would require more discussion, so short term (0.94.1 at least), we could remove the Put/Delete/Get metrics as you suggest.
        Hide
        Andrew Purtell added a comment - - edited

        Perhaps not a full revert, but the "put" and "delete" metrics are not useful in a basic LoadTestTool test scenario, so consider dropping those. The distinction is increasingly only valid client side. Perhaps also remove the "get" one as well so we're not in effect special casing a metric only into HRI.get().

        Edit: But even after the above, the histograms remain for FS level ops, so there's benefit to a partial revert only.

        Show
        Andrew Purtell added a comment - - edited Perhaps not a full revert, but the "put" and "delete" metrics are not useful in a basic LoadTestTool test scenario, so consider dropping those. The distinction is increasingly only valid client side. Perhaps also remove the "get" one as well so we're not in effect special casing a metric only into HRI.get(). Edit: But even after the above, the histograms remain for FS level ops, so there's benefit to a partial revert only.
        Hide
        Lars Hofhansl added a comment -

        I'd be supportive of reverting HBASE-5533 until we work out a clear strategy of what we're measuring and when.

        Show
        Lars Hofhansl added a comment - I'd be supportive of reverting HBASE-5533 until we work out a clear strategy of what we're measuring and when.
        Hide
        Lars Hofhansl added a comment -

        I "knew" there would be issues somewhere with HBASE-6284
        What do you say Andrew, this seems bad enough to delay 0.94.1?

        Does a "Put" metric still make sense? Should it be a "Mutation" metric which includes Deletes?

        Show
        Lars Hofhansl added a comment - I "knew" there would be issues somewhere with HBASE-6284 What do you say Andrew, this seems bad enough to delay 0.94.1? Does a "Put" metric still make sense? Should it be a "Mutation" metric which includes Deletes?
        Hide
        Andrew Purtell added a comment -

        Other means for applying puts and deletes (RowMutations etc.) are not covered either, neither are Increments, or Appends. Perhaps this is an argument for reverting HBASE-5533.

        Show
        Andrew Purtell added a comment - Other means for applying puts and deletes (RowMutations etc.) are not covered either, neither are Increments, or Appends. Perhaps this is an argument for reverting HBASE-5533 .
        Andrew Purtell made changes -
        Field Original Value New Value
        Affects Version/s 0.96.0 [ 12320040 ]
        Affects Version/s 0.94.1 [ 12320257 ]
        Component/s metrics [ 12314281 ]
        Component/s regionserver [ 12312139 ]
        Andrew Purtell created issue -

          People

          • Assignee:
            Andrew Purtell
            Reporter:
            Andrew Purtell
          • Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development