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

[WIP] Throttling filter #410

Closed
wants to merge 9 commits into from
Closed

[WIP] Throttling filter #410

wants to merge 9 commits into from

Conversation

onorua
Copy link
Contributor

@onorua onorua commented Nov 1, 2017

There are cases when you need to handle only the load you agreed on, and drop the rest (some sort of internal service with SLA). This plugin does exactly this. We have some rate per second, and we drop messages above it. It implements leaky bucket, based on sliding window algorithm.

There are couple of things we could improve on though (looking forward to your suggestions):

  1. I would like to have a background time ticker, don't know how to make it using fluent-bit framework. Should I wake up on the event, or some background thread is enough.
  2. Do you think we need different time ranges, like per minute, per hour etc?
  3. Do think anything can be improved? I got 1 core nocked out for more than 100k req/sec.

What do you think about the idea in general?

@onorua onorua changed the title Throttling filter [WIP] Throttling filter Nov 1, 2017
@onorua
Copy link
Contributor Author

onorua commented Nov 6, 2017

@edsiper should I create something similar to flb_input_set_collector_time for filter? Do you think such a functionality can be merged when done, or this is something you don't want in mainline?

@edsiper
Copy link
Member

edsiper commented Nov 6, 2017

hi @onorua

If this plugin is for a production use-case I am happy to have it there.

regarding your questions:

  1. I would like to have a background time ticker, don't know how to make it using fluent-bit framework
    Ideally this need to have a time_collector into the filters which don't exists at the moment. I think it's necessary, I can add the bits for that.

  2. Should I wake up on the event, or some background thread is enough.
    I think Fix include paths #1 is enough

  3. Do you think we need different time ranges, like per minute, per hour etc?
    do you have more use-cases ?, I would like to learn more from that.

  4. Do think anything can be improved? I got 1 core nocked out for more than 100k req/sec.
    do you mean to increase performance ?

@edsiper
Copy link
Member

edsiper commented Jan 15, 2018

@onorua are you still interested into merge improve this feature ?

@onorua
Copy link
Contributor Author

onorua commented Jan 15, 2018

Yes, we have this in production for some time and really happy about it. Give me couple of days for tests coverage. I'll split this PR into 2 PRs one for throttling and another one for elastic search index regexp.

@onorua
Copy link
Contributor Author

onorua commented Feb 18, 2018

closing in favor of #511

@onorua onorua closed this Feb 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants