[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17800388#comment-17800388
]
Maxim Muzafarov commented on CASSANDRA-14572:
---------------------------------------------
Here is the latest benchmark for selecting a metric by its name (no GC pressure
and low latency):
{code:bash}
SUMMARY STATS
═════════════════════════════════════════════════════════════════════════
Elapsed time [s] 60.001
CPU time [s] 56.884
CPU utilisation [%] 9.5
Cycles [op] 15877269
Errors [op] 0
└─ [%] 0.0
Requests [req] 15877269
└─ [req/op] 1.0
Rows [row] 15877269
└─ [row/req] 1.0
Samples 60
Mean sample size [op] 264621
└─ [req] 264621
Concurrency [req] 95 ± 0
└─ [%] 74
Throughput [op/s] 264620 ± 32548
├─ [req/s] 264620 ± 32548
└─ [row/s] 264620 ± 32548
Mean cycle time [ms] 0.380 ± 0.054
Mean resp. time [ms] 0.379 ± 0.054
RESPONSE TIMES [ms]
══════════════════════════════════════════════════════════════════
Min 0.254 ± 0.007
25 0.332 ± 0.023
50 0.355 ± 0.042
75 0.393 ± 0.067
90 0.460 ± 0.096
95 0.515 ± 0.128
98 0.597 ± 0.191
99 0.687 ± 0.299
99.9 1.564 ± 1.852
99.99 4.751 ± 3.954
Max 5.140 ± 4.801
RESPONSE TIME DISTRIBUTION
═══════════════════════════════════════════════════════════
── Resp. time [ms] ── ─────────────────────────────────── Count
─────────────────────
0.0 ... 0.1 0 0.00%
0.1 ... 0.2 12 0.00%
0.2 ... 0.5 14383348 90.59%
▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪
0.5 ... 1.0 1414480 8.91% ▪▪▪▪▪▪▪▪
1.0 ... 2.2 64692 0.41%
2.2 ... 4.6 9087 0.06%
4.6 ... 10.0 4593 0.03%
10.0 ... 21.5 504 0.00%
21.5 ... 46.4 466 0.00%
46.4 ... 100.0 87 0.00%
{code}
> Expose all table metrics in virtual table
> -----------------------------------------
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
> Reporter: Chris Lohfink
> Assignee: Maxim Muzafarov
> Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, select keyspaces_group by string prefix.png, select
> keyspaces_group compare with wo.png, select keyspaces_group without
> value.png, systemv_views.metrics_dropped_message.png, thread_pools
> benchmark.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map<Text, Text> style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
