Rate limiting via socket#899
Conversation
cf-foundation-community-automation
Bot
moved this to Inbox
in Application Runtime Platform Working Group
Dariquest
force-pushed
the
socket-rate-limit
branch
from
000e8d8 to
7cdd1d9
Compare
Mrizwanshaik
force-pushed
the
socket-rate-limit
branch
from
a3126b6 to
2815bf2
Compare
Rate limiting via socket Rate limiting via socket
add acceptance test for connection rate limit via socket Co-authored-by: Dariquest <daria.anton@sap.com> fix indentation in config enhance acceptance tests optimize acceptance for connection rate limiting via socket add root permission to socat
Mrizwanshaik
force-pushed
the
socket-rate-limit
branch
from
1b29569 to
d946c87
Compare
a18e
left a comment
a18e
left a comment
There was a problem hiding this comment.
Approval for CI - did not review yet.
github-project-automation
Bot
moved this from Inbox
to Pending Merge | Prioritized
in Application Runtime Platform Working Group
| tcp-request connection reject if { sc_conn_rate(0) gt <%= connections %> } | ||
| <%- end -%> | ||
| <%- end -%> | ||
| tcp-request connection reject if { var(proc.conn_rate_limit_enabled) -m bool } { sc_conn_rate(0),sub(proc.conn_rate_limit) gt 0 } |
There was a problem hiding this comment.
Why do we substract instead of comparing directly? Did you test that this is more performant?
There was a problem hiding this comment.
Yeah I tried with comparison first but turns our haproxy comparator expects static integer on the right, not variables reference in any form. Subtraction approach is a way to compare against dynamic variables.
|
|
||
| By("Overriding the limit at runtime via socket to a higher value") | ||
| newLimit := connLimit * 3 | ||
| runHAProxySocketCommand(haproxyInfo, fmt.Sprintf("experimental-mode on; set var proc.conn_rate_limit int(%d)", newLimit)) |
There was a problem hiding this comment.
Did you investigate what the drawbacks of experimental-mode are? Do we even still require this? How long will this stay experimental?
There was a problem hiding this comment.
set var is only available in experimental mode (since HAProxy 2.4, HAProxy Enterprise 2.4r1). Unfortunately, this operation is still in development and may change in the future (see HAProxy documentation).
There was a problem hiding this comment.
This is by design from haproxy version until now, this commands are still in development mode and may change later on. see: https://www.haproxy.com/documentation/haproxy-runtime-api/reference/set-var/ and https://www.haproxy.com/documentation/haproxy-runtime-api/reference/experimental-mode/
Drawback: Its per-connection only - doesn't persist across sessions. experimental-mode on is required because set var is classified as an experimental/unstable feature in HAProxy's runtime API
| tcp-request connection reject if { sc_conn_rate(0) gt <%= connections %> } | ||
| <%- end -%> | ||
| <%- end -%> | ||
| tcp-request connection reject if { var(proc.conn_rate_limit_enabled) -m bool } { sc_conn_rate(0),sub(proc.conn_rate_limit) gt 0 } |
There was a problem hiding this comment.
| tcp-request connection reject if { var(proc.conn_rate_limit_enabled) -m bool } { sc_conn_rate(0),sub(proc.conn_rate_limit) gt 0 } | |
| tcp-request connection silent-drop if { var(proc.conn_rate_limit_enabled) -m bool } { sc_conn_rate(0),sub(proc.conn_rate_limit) gt 0 } |
I think we should do this, even though it's a breaking change.
Yes, this will be worse for valid clients in but we work under the assumption that rate limits will only be enforced under heavy load scenarios where it's acceptable to negatively affect some valid traffic in order to prevent a complete outage.
3 participants
Rate limiting can be configured via socket, so that it is possible to adjust rate limits when haproxy is under high load.