Feature Request: Allow updating the limit about ratelimit

[rabbbit]

Hi,

Would you elaborate on the use case for this? Do you have a project already, or is it a theoretical interest?

[prathik]

@rabbbit I am working on it and evaluating various rate limiters. This is inspired by https://github.com/Netflix/concurrency-limits and wanted to reuse any existing libraries if present.

[xiaoyang-chen]

Goal: To use this library with an adaptive rate limiter algorithm like Vegas or AIMD

Problem: Right now the library exposes no way to update the rates dynamically.

There are two ways to solve for this

1. Create a new rate limiter every time I want to update limits
2. Dynamically update the rate limit on the object

Would like feedback on which is the preferred approach. Or if there is any other way.

I read the go files in this repo, first way is the better way for this ratelimit, I think, because limit is not direct influence to this ratelimit

[prathik]

@rabbbit If we update the perRequest value in limiter_atomic.go:41 we should be able to dynamically change the rate. Can I go ahead and contribute? Or do you prefer that we stick to create a new ratelimit object when we want to change the rate?

[rabbbit]

It's not just perRequest. Since we also store slack, we'd need to update (or throw away?) the actual slack value. We'd also need to do it atomically, so there's extra complexity there.

Is creating a new limiter feasible? If so, that would be my preference.

[prathik]

@rabbbit sure, I don't see any concerns with it, at worst case scenario we'd be creating a new object every couple of seconds till we hit a stable point. You see any concerns with that?

[prathik]

@rabbbit BTW I'm implementing Vegas congestion control on top of this library.

[rabbbit]

If it works for you, please go that way then :)

…

On Wed, 17 Mar 2021 at 11:37, Prathik Rajendran M ***@***.***> wrote: @rabbbit <https://github.com/rabbbit> BTW I'm implementing Vegas congestion control on top of this library. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACG3UWWUSNWFZAH5BFO57TTEDEBXANCNFSM4YMSQIRQ> .