[jira] [Updated] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17423:
Source Control Link:
https://github.com/apache/cassandra/commit/4ea3e4c5050ba11a5b7897af74bb54e7e8dad068
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed in
https://github.com/apache/cassandra/commit/4ea3e4c5050ba11a5b7897af74bb54e7e8dad068
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> \* We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17423:
Status: Review In Progress (was: Patch Available)
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> \* We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17423:
Status: Ready to Commit (was: Review In Progress)
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> \* We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17423:
--
Reviewers: Josh McKenzie
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> \* We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17423:
Test and Documentation Plan:
* NEWS entry describing the two new cassandra.yaml options
* inline documentation in cassandra.yaml for native protocol rate limiting
options
* basic tests to verify expectations around marking against the new dispatch
rate metric
Status: Patch Available (was: In Progress)
|trunk|
|[branch|https://github.com/apache/cassandra/pull/1500]|
|[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17423&filter=all]|
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> \* We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17423:
Description:
In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
requests over the native transport. Given it has now had some time to marinate
in 4.1 snapshot builds, there are a few things we should do to make sure it
hits the bar for usability and observability:
1.) Add the {{native_transport_rate_limiting_enabled}} and
{{native_transport_max_requests_per_second}} options to the example
{{cassandra.yaml}} file w/ brief documentation.
2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
native transport requests dispatched for processing. Given there are a few
cases where native transport requests may not translate 1:1 to the number of
times we hit StorageProxy, having this metric should make verifying the correct
operation of the limiter easier. (Ex. IN queries w/ multiple partition keys,
{{GROUP BY}} queries, etc.) It may make sense to look further into adjusting
the behavior of the rate limiter to take these kinds of queries into account,
but that is a bit more complex than either of these 2 items, and deserves
another Jira.
\* We do expose a per-connection counter for the number of requests dispatched,
and it is exposed over a virtual table and JMX, but even if it were global, it
is not a rate metric.
was:
In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
requests over the native transport. Given it has now had some time to marinate
in 4.1 snapshot builds, there are a few things we should do to make sure it
hits the bar for usability and observability:
1.) Add the {{native_transport_rate_limiting_enabled}} and
{{native_transport_max_requests_per_second}} options to the example
{{cassandra.yaml}} file w/ brief documentation.
2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
native transport requests dispatched for processing. Given there are a few
cases where native transport requests may not translate 1:1 to the number of
times we hit StorageProxy, having this metric should make verifying the correct
operation of the limiter easier. (Ex. IN queries w/ multiple partition keys,
{{GROUP BY}} queries, etc.) It may make sense to look further into adjusting
the behavior of the rate limiter to take these kinds of queries into account,
but that is a bit more complex than either of these 2 items, and deserves
another Jira.
* We do expose a per-connection counter for the number of requests dispatched,
and it is exposed over a virtual table and JMX, but even if it were global, it
is not a rate metric.
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> \* We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17423:
Change Category: Operability
Complexity: Normal
Component/s: Local/Config
Observability/Metrics
Status: Open (was: Triage Needed)
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config, Observability/Metrics
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> * We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17423) Add Native Transport Rate Limiter Options to Example cassandra.yaml and Expose Metric for Dispatch Rate
[
https://issues.apache.org/jira/browse/CASSANDRA-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17423:
Fix Version/s: 4.1
> Add Native Transport Rate Limiter Options to Example cassandra.yaml and
> Expose Metric for Dispatch Rate
> ---
>
> Key: CASSANDRA-17423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17423
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1
>
>
> In CASSANDRA-16663, we added a new rate limiter that applies to all incoming
> requests over the native transport. Given it has now had some time to
> marinate in 4.1 snapshot builds, there are a few things we should do to make
> sure it hits the bar for usability and observability:
> 1.) Add the {{native_transport_rate_limiting_enabled}} and
> {{native_transport_max_requests_per_second}} options to the example
> {{cassandra.yaml}} file w/ brief documentation.
> 2.) Add a simple Meter/metric, probably in {{ClientMetrics}} for the rate* of
> native transport requests dispatched for processing. Given there are a few
> cases where native transport requests may not translate 1:1 to the number of
> times we hit StorageProxy, having this metric should make verifying the
> correct operation of the limiter easier. (Ex. IN queries w/ multiple
> partition keys, {{GROUP BY}} queries, etc.) It may make sense to look further
> into adjusting the behavior of the rate limiter to take these kinds of
> queries into account, but that is a bit more complex than either of these 2
> items, and deserves another Jira.
> * We do expose a per-connection counter for the number of requests
> dispatched, and it is exposed over a virtual table and JMX, but even if it
> were global, it is not a rate metric.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
