[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Attachment: SSTablePerReadHistogram_RowCache_trunk.patch > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Assignee: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch, > SSTablePerReadHistogram_RowCache_trunk.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15036122#comment-15036122 ] Ivan Burmistrov commented on CASSANDRA-10585: - I've attached patch for trunk (and it works for 3.0 too). > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Assignee: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch, > SSTablePerReadHistogram_RowCache_trunk.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Attachment: (was: SSTablePerReadHistogram_RowCache-cassandra-3_0.patch) > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Attachment: SSTablePerReadHistogram_RowCache-cassandra-2_2.patch > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Attachment: (was: SSTablePerReadHistogram_RowCache-cassandra-2_2.patch) > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-3_0.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15020444#comment-15020444 ] Ivan Burmistrov commented on CASSANDRA-10585: - I've reattached patch for 2.2: I've added the ability to consider 0 values in EstimatedHistogram and SSTablesPerReadHistogram uses this ability now. If it is OK, I will prepare patches for 3.0 and trunk. > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010712#comment-15010712 ] Ivan Burmistrov commented on CASSANDRA-10585: - I think, extending EstimatedHistogram to properly capture a 0 value is more preferably. Because not only row cache may cause reading 0 SSTables, but [CASSANDRA-2498|https://issues.apache.org/jira/browse/CASSANDRA-2498] and [CASSANDRA-5514|https://issues.apache.org/jira/browse/CASSANDRA-5514] optimizations too: read request can process only Memtable without touching any SSTable if these optimizations work well. I will prepare new versions of patches and will attach it for your review soon. > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch, > SSTablePerReadHistogram_RowCache-cassandra-3_0.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003635#comment-15003635 ] Ivan Burmistrov edited comment on CASSANDRA-10585 at 11/13/15 11:44 AM: I prepared patches to versions 2.1, 2.2 and 3.0 (and it is not hard to prepare patch for trunk). Important comment for 2.2 and 3.0 versions. SSTablePerReadHistogram in these versions is EstimatedHistogram now. But for this implementation of histogram zero values make almost no effect. It seems not good, because it is important to know if, for example, we read 0.1 SSTables per read at average. For example, we want to know does [CASSANDRA-2498|https://issues.apache.org/jira/browse/CASSANDRA-2498] or [CASSANDRA-5514|https://issues.apache.org/jira/browse/CASSANDRA-5514] optimization works for some table. EstimatedHistogram returns only integer values and make this scenario impossible, while it was possible in versions 2.1 and below. So in patches for 2.2 and 3.0 I switched SSTablesPerReadHistogram to ExponentiallyDecayingHistogram implementation. was (Author: isburmistrov): I have prepared patches to versions 2.1, 2.2 and 3.0 (and it is not hard to prepare patch for trunk). Important comment for 2.2 and 3.0 versions. SSTablePerReadHistogram in these versions is EstimatedHistogram now. But for this implementation of histogram zero values make almost no effect. It seems not good, because it is important to know if, for example, we read 0.1 SSTables per read at average. For example, we want to know does [CASSANDRA-2498|https://issues.apache.org/jira/browse/CASSANDRA-2498] or [CASSANDRA-5514|https://issues.apache.org/jira/browse/CASSANDRA-5514] optimization works for some table. EstimatedHistogram returns only integer values and make this scenario impossible, while it was possible in versions 2.1 and below. So in patches for 2.2 and 3.0 I switched SSTablesPerReadHistogram to ExponentiallyDecayingHistogram implementation. > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch, > SSTablePerReadHistogram_RowCache-cassandra-3_0.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Flags: Patch Attachment: SSTablePerReadHistogram_RowCache-cassandra-3_0.patch SSTablePerReadHistogram_RowCache-cassandra-2_2.patch SSTablePerReadHistogram_RowCache-cassandra-2_1.patch Fix Version/s: 3.0.x 2.2.x > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch, > SSTablePerReadHistogram_RowCache-cassandra-3_0.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003635#comment-15003635 ] Ivan Burmistrov commented on CASSANDRA-10585: - I have prepared patches to versions 2.1, 2.2 and 3.0 (and it is not hard to prepare patch for trunk). Important comment for 2.2 and 3.0 versions. SSTablePerReadHistogram in these versions is EstimatedHistogram now. But for this implementation of histogram zero values make almost no effect. It seems not good, because it is important to know if, for example, we read 0.1 SSTables per read at average. For example, we want to know do https://issues.apache.org/jira/browse/CASSANDRA-2498 and https://issues.apache.org/jira/browse/CASSANDRA-5514 optimizations works for some table. EstimatedHistogram returns only integer values and make this scenario impossible, while it was possible in versions 2.1 and below. So in patches for 2.2 and 3.0 I switched SSTablesPerReadHistogram to ExponentiallyDecayingHistogram implementation. > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch, > SSTablePerReadHistogram_RowCache-cassandra-3_0.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003635#comment-15003635 ] Ivan Burmistrov edited comment on CASSANDRA-10585 at 11/13/15 7:02 AM: --- I have prepared patches to versions 2.1, 2.2 and 3.0 (and it is not hard to prepare patch for trunk). Important comment for 2.2 and 3.0 versions. SSTablePerReadHistogram in these versions is EstimatedHistogram now. But for this implementation of histogram zero values make almost no effect. It seems not good, because it is important to know if, for example, we read 0.1 SSTables per read at average. For example, we want to know do [CASSANDRA-2498|https://issues.apache.org/jira/browse/CASSANDRA-2498] and [CASSANDRA-5514|https://issues.apache.org/jira/browse/CASSANDRA-5514] optimizations works for some table. EstimatedHistogram returns only integer values and make this scenario impossible, while it was possible in versions 2.1 and below. So in patches for 2.2 and 3.0 I switched SSTablesPerReadHistogram to ExponentiallyDecayingHistogram implementation. was (Author: isburmistrov): I have prepared patches to versions 2.1, 2.2 and 3.0 (and it is not hard to prepare patch for trunk). Important comment for 2.2 and 3.0 versions. SSTablePerReadHistogram in these versions is EstimatedHistogram now. But for this implementation of histogram zero values make almost no effect. It seems not good, because it is important to know if, for example, we read 0.1 SSTables per read at average. For example, we want to know do https://issues.apache.org/jira/browse/CASSANDRA-2498 and https://issues.apache.org/jira/browse/CASSANDRA-5514 optimizations works for some table. EstimatedHistogram returns only integer values and make this scenario impossible, while it was possible in versions 2.1 and below. So in patches for 2.2 and 3.0 I switched SSTablesPerReadHistogram to ExponentiallyDecayingHistogram implementation. > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch, > SSTablePerReadHistogram_RowCache-cassandra-3_0.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Attachment: (was: cassandra-10585.patch) > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch, > SSTablePerReadHistogram_RowCache-cassandra-3_0.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003635#comment-15003635 ] Ivan Burmistrov edited comment on CASSANDRA-10585 at 11/13/15 7:02 AM: --- I have prepared patches to versions 2.1, 2.2 and 3.0 (and it is not hard to prepare patch for trunk). Important comment for 2.2 and 3.0 versions. SSTablePerReadHistogram in these versions is EstimatedHistogram now. But for this implementation of histogram zero values make almost no effect. It seems not good, because it is important to know if, for example, we read 0.1 SSTables per read at average. For example, we want to know does [CASSANDRA-2498|https://issues.apache.org/jira/browse/CASSANDRA-2498] or [CASSANDRA-5514|https://issues.apache.org/jira/browse/CASSANDRA-5514] optimization works for some table. EstimatedHistogram returns only integer values and make this scenario impossible, while it was possible in versions 2.1 and below. So in patches for 2.2 and 3.0 I switched SSTablesPerReadHistogram to ExponentiallyDecayingHistogram implementation. was (Author: isburmistrov): I have prepared patches to versions 2.1, 2.2 and 3.0 (and it is not hard to prepare patch for trunk). Important comment for 2.2 and 3.0 versions. SSTablePerReadHistogram in these versions is EstimatedHistogram now. But for this implementation of histogram zero values make almost no effect. It seems not good, because it is important to know if, for example, we read 0.1 SSTables per read at average. For example, we want to know do [CASSANDRA-2498|https://issues.apache.org/jira/browse/CASSANDRA-2498] and [CASSANDRA-5514|https://issues.apache.org/jira/browse/CASSANDRA-5514] optimizations works for some table. EstimatedHistogram returns only integer values and make this scenario impossible, while it was possible in versions 2.1 and below. So in patches for 2.2 and 3.0 I switched SSTablesPerReadHistogram to ExponentiallyDecayingHistogram implementation. > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch, > SSTablePerReadHistogram_RowCache-cassandra-3_0.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Burmistrov updated CASSANDRA-10585: Attachment: cassandra-10585.patch Description: SSTablePerReadHistogram metric now not considers case when row has been read from row cache. And so, this metric will have big values even almost all requests processed by row cache (and without touching SSTables, of course). So, it seems that correct behavior is to consider that if we read row from row cache then we read zero SSTables by this request. The patch at the attachment. was: SSTablePerReadHistogram metric now not considers case when row has been read from row cache. And so, this metric will have big values even almost all requests processed by row cache (and without touching SSTables, of course). So, it seems that correct behavior is to consider that if we read row from row cache then we read zero SSTables by this request. > SSTablesPerReadHistogram seems wrong when row cache hit happend > --- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Ivan Burmistrov >Priority: Minor > Fix For: 2.1.x > > Attachments: cassandra-10585.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10585) SSTablesPerReadHistogram seems wrong when row cache hit happend
Ivan Burmistrov created CASSANDRA-10585: --- Summary: SSTablesPerReadHistogram seems wrong when row cache hit happend Key: CASSANDRA-10585 URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 Project: Cassandra Issue Type: Bug Components: Core Reporter: Ivan Burmistrov Priority: Minor Fix For: 2.1.x SSTablePerReadHistogram metric now not considers case when row has been read from row cache. And so, this metric will have big values even almost all requests processed by row cache (and without touching SSTables, of course). So, it seems that correct behavior is to consider that if we read row from row cache then we read zero SSTables by this request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
