Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 13 Nov 2015 11:45:10 +0000 (UTC)
From: "Ivan Burmistrov (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12907500.1445624103000.60531.1447415110954@Atlassian.JIRA>
In-Reply-To: <JIRA.12907500.1445624103000@Atlassian.JIRA>
References: <JIRA.12907500.1445624103000@Atlassian.JIRA>
 <JIRA.12907500.1445624103048@arcas>
Subject: [jira] [Comment Edited] (CASSANDRA-10585) SSTablesPerReadHistogram
 seems wrong when row cache hit happend
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)