cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3469) More fine-grained request statistics
Date Tue, 08 Nov 2011 03:10:52 GMT


Jonathan Ellis commented on CASSANDRA-3469:

I'm picturing something like

class RequestStats {
    EstimatedHistogram latency, sstablesRead, columnCount, rowCount

Map<QueryIdentifier, RequestStats> stats;

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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message