-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Ratelimit plugin not working as expected - kong 1.4 #5311
Comments
Currently rate-limiting is counted async, the function is created here on And it is executed here on |
I think on high load, the timer that is executed on |
On Kong Enterprise we have this (which does not run timers on each request): |
@jogendrajangid1, would you like to try: #5460, and give feedback? |
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix Kong#5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
We have to buy Kong Enterprise to use it right? |
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
### Summary Context: - starting `timers` on busy servers on each request will just move the load elsewhere - there is little change that upstream sets rate-limiting headers, so we can just set them on access So this PR removes timers and all the phase handlers except `access` from rate-limiting plugin. Yes, it might add some latency to request, but on a bright side we have more accurate rate-limits. This PR does change the rate-limiting consistency mode. ### Issues Resolved This might fix #5311
### Summary The PR #5460 tried to fix rate-limiting accuracy issues as reported with #5311. That PR has stayed open for over a year now. There is a smaller change in that PR that we can make without a lot of work or debating, and this PR contains that only: 1. it removes extra phase handlers and context passing of data and now does everything in `access` phase (this could make it more accurate as well, compared to post-poning that to log phase) 2. it now also sets rate-limiting headers when the limits have exceeded
…#6802) ### Summary The PR #5460 tried to fix rate-limiting accuracy issues as reported with #5311. That PR has stayed open for over a year now. There is a smaller change in that PR that we can make without a lot of work or debating, and this PR contains that only: 1. it removes extra phase handlers and context passing of data and now does everything in `access` phase (this could make it more accurate as well, compared to post-poning that to log phase) 2. it now also sets rate-limiting headers when the limits have exceeded
@jogendrajangid1 you can reproduce your scenario with the version of PR: #7831 that will work |
Kong 1.4 came out in October 2019 and is not longer supported. |
it is same fix made in PR #8227, but I remove sliding-window feature. Kong have no plans to add a sliding window to this plugin, Sliding window is an enterprise-only feature at this point
Summary
I have configured rate-limit plugin with key-auth. 5 req/sec is working fine if requests are more then 50 per seconds its not detecting. i have tried out with cluster/local/redis policy.
SUMMARY_GOES_HERE
Steps To Reproduce
kong 1.4 . cassandra backend. deploy on kubernets
Additional Details & Logs
$ kong version
) v1.4$ kong start --vv
)<KONG_PREFIX>/logs/error.log
)https://docs.konghq.com/latest/admin-api/#retrieve-node-information)
The text was updated successfully, but these errors were encountered: