Skip to content
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

[request] Throttling Control #234

Closed
ahmadnassri opened this issue May 13, 2015 · 5 comments
Closed

[request] Throttling Control #234

ahmadnassri opened this issue May 13, 2015 · 5 comments
Assignees
Labels
idea/new plugin [legacy] those issues belong to Kong Nation, since GitHub issues are reserved for bug reports.

Comments

@ahmadnassri
Copy link
Contributor

Definition:

Throttling is to defer operations, where requests can be suspended or curtailed, with an exception generated to inform the consumer that the system is busy and that the operation should be retried later.

Thoughts / Ideas:

  • Rejecting requests from consumers who have already requested certain endpoints more than n times per x time unit (seconds, minutes, etc ...) over a given period of time.
  • Disabling or downgrading tiers of offending consumers based on same rules
  • Defaulting to cache for throttled consumers?
@ahmadnassri ahmadnassri added idea/new plugin [legacy] those issues belong to Kong Nation, since GitHub issues are reserved for bug reports. request labels May 13, 2015
@thibaultcha thibaultcha changed the title Throttling Control [request] Throttling Control May 13, 2015
@tamizhgeek
Copy link
Contributor

Isn't the rejecting requests from consumers already available via ratelimting plugin?

@ahmadnassri
Copy link
Contributor Author

@tamizhgeek there could be significant difference between a traditional rate limiting behaviour and throttling. there also overlap in certain aspects.

in this case, throttling is dynamic over a range of time, vs. with rate limiting it's a fixed limit to a time unit.

e.g. you can have BOTH rules working together:

rate limiting:
500 req / day
1000 req / month total
each count towards upper limit
primarily used to limit access to data over time.

throttle:
100 req / secons
no upper limits / counting towards rate quotas.
primarily used to slow down requests to avoid server overload

also, since this would be a separate plugin would need it's own logic for rejecting requests...

@livingos
Copy link

+1 for a throttling plugin. One of the missing features compared to alternative solutions.

@subnetmarco subnetmarco self-assigned this Feb 4, 2016
@ahmadnassri ahmadnassri added the BC label May 13, 2016
@thibaultcha thibaultcha removed the BC label Sep 1, 2016
@hishamhm hishamhm closed this as completed May 3, 2018
kikito added a commit to Kong/docs.konghq.com that referenced this issue May 23, 2018
@tomodutch
Copy link

I was searching for a plugging like this. This issue is closed now and I don't see a throttle plugin on the kong website. Are there any alternatives that implement this behaviour?

@coopr
Copy link
Contributor

coopr commented Jul 25, 2018

Kong Enterprise Edition (EE) includes https://docs.konghq.com/enterprise/latest/plugins/rate-limiting-advanced/ plugin which offers a sliding window option. Using a sliding window has the effect of limiting the rate of requests - requests occurring at a consistently excessive rate will be rejected. More details are available here https://docs.konghq.com/enterprise/latest/rate-limiting/ and here https://konghq.com/blog/how-to-design-a-scalable-rate-limiting-algorithm/

Going forward, please move the discussion of features to Kong Nation https://discuss.konghq.com/ - Github Issues are reserved for bug reports. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea/new plugin [legacy] those issues belong to Kong Nation, since GitHub issues are reserved for bug reports.
Projects
None yet
Development

No branches or pull requests

8 participants