[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] [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] [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)
