cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Lerer (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12649) Add BATCH metrics
Date Mon, 07 Nov 2016 21:41:59 GMT


Benjamin Lerer commented on CASSANDRA-12649:

I had a discussion earlier today with [~tjake] who has more experience than me with Cassandra
performance and Stress. It pointed out to me that we already use {{PartitionUpdate::dataSize}}
to issue batch size warnings in {{BatchStatement::verifyBatchSize}}. His suggestion was to
move the metric to {{BatchStatement}} as it will allow the patch to reuse the result of the
existing call and avoid having the to compute the size on each replica.
The idea would be then to add that metric to your {{BatchMetrics}} instead of adding it to

I looked at {{BatchStatement}} and it seems that the {{verifyBatchSize}} is only called for
batch without conditions. I opened CASSANDRA-12885 to address that problem. If you can fix
it first, it would be great :-).

Regarding your initial patch, I also have the following nits:
* {{BatchMetrics}} has a start method that does nothing and should be removed (including the
call to it in StorageService)
* Instead of making {{BatchMetrics}} a singleton you could have a public static variable in
{{BatchStatement}} (similar to {{CQLMetrics}} in {{QueryProcessor}}) as it is more inline
with the rest of the code.
* It would be nice if you could add the documentation for those new metrics in {{doc/source/operating/metrics.rts}}


> Add BATCH metrics
> -----------------
>                 Key: CASSANDRA-12649
>                 URL:
>             Project: Cassandra
>          Issue Type: Wish
>            Reporter: Alwyn Davis
>            Priority: Minor
>             Fix For: 3.x
>         Attachments: 12649-3.x.patch, stress-batch-metrics.tar.gz, stress-trunk.tar.gz,
> To identify causes of load on a cluster, it would be useful to have some additional metrics:
> * *Mutation size distribution:* I believe this would be relevant when tracking the performance
of unlogged batches.
> * *Logged / Unlogged Partitions per batch distribution:* This would also give a count
of batch types processed. Multiple distinct tables in batch would just be considered as separate

This message was sent by Atlassian JIRA

View raw message