Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 8 Nov 2011 03:10:52 +0000 (UTC)
From: "Jonathan Ellis (Commented) (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <654749704.9580.1320721852045.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <740379786.9556.1320721613469.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-3469) More fine-grained request
 statistics
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146056#comment-13146056 ] 

Jonathan Ellis commented on CASSANDRA-3469:
-------------------------------------------

I'm picturing something like

{code}
class RequestStats {
    EstimatedHistogram latency, sstablesRead, columnCount, rowCount
}

Map<QueryIdentifier, RequestStats> stats;
{code}

The QueryIdentifier piece will be the interesting part!

This is starting to feel relatively heavyweight, so we might need to add the ability to enable/disable stat tracking via JMX.  Or maybe we allow tracking a fraction from 0 to 1, as with ReadRepairChance.  Of course we should benchmark before assuming this is the case.
                
> More fine-grained request statistics
> ------------------------------------
>
>                 Key: CASSANDRA-3469
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3469
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Yuki Morishita
>            Priority: Minor
>             Fix For: 1.1
>
>
> It would be useful to split the CFS stats up by query type.  slice vs named vs range vs index, to start with (right now we don't track range scans at all), but also at the "prepared statement" level as it were:
> {{SELECT x FROM foo WHERE key = ?}} would be one query no matter what the ? is, but {{SELECT y FROM foo WHERE key = ?}} would be different.  {{SELECT x..y FROM foo WHERE key = ?}} would be another, as would {{SELECT x FROM foo WHERE key = ? AND bar= ?}}.  (But {{SELECT x FROM foo WHERE bar = ? AND key = ?}} would be identical to the former, of course.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira