-
Notifications
You must be signed in to change notification settings - Fork 766
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rpc server: add prometheus label is_rate_limited
#3504
Conversation
is_rate_limited
is_rate_limited
let middleware_layer = match (metrics, rate_limit) { | ||
(None, None) => None, | ||
(Some(metrics), None) => Some( | ||
MiddlewareLayer::new().with_metrics(Metrics::new(metrics, transport_label)), | ||
), | ||
(None, Some(rate_limit)) => | ||
Some(MiddlewareLayer::new().with_rate_limit_per_minute(rate_limit)), | ||
(Some(metrics), Some(rate_limit)) => Some( | ||
MiddlewareLayer::new() | ||
.with_metrics(Metrics::new(metrics, transport_label)) | ||
.with_rate_limit_per_minute(rate_limit), | ||
), | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it be possible to do something like this instead to simplify a bit?:
let mut middleware_layer = MiddlewareLayer::new();
if let Some(metrics) = metrics {
middleware_layer = middleware_layer.with_metrics(Metrics::new(metrics, transport_label));
}
if let Some(rate_limit) = rate_limit {
middleware_layer = middleware_layer.with_rate_limit_per_minute(rate_limit);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's possible but it doesn't make sense to enable middleware if it's empty that's why I did it like that i.e, to box the future when it's a no-op middleware.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Co-authored-by: James Wilson <james@jsdw.me>
After some discussion with @kogeler after the we added the rate-limit middleware it may slow down the rpc call timings metrics significantly because it works as follows: 1. The rate limit guard is checked when the call comes and if a slot is available -> process the call 2. If no free spot is available then the call will be sleeping `jitter_delay + min_time_rate_guard` then woken up and checked at most ten times 3. If no spot is available after 10 iterations -> the call is rejected (this may take tens of seconds) Thus, this PR adds a label "is_rate_limited" to filter those out on the metrics "substrate_rpc_calls_time" and "substrate_rpc_calls_finished". I had to merge two middleware layers Metrics and RateLimit to avoid shared state in a hacky way. --------- Co-authored-by: James Wilson <james@jsdw.me>
After some discussion with @kogeler after the we added the rate-limit middleware it may slow down
the rpc call timings metrics significantly because it works as follows:
jitter_delay + min_time_rate_guard
then woken up and checked at most ten timesThus, this PR adds a label "is_rate_limited" to filter those out on the metrics "substrate_rpc_calls_time" and "substrate_rpc_calls_finished".
I had to merge two middleware layers Metrics and RateLimit to avoid shared state in a hacky way.