search

ruslandoga / rate_limit

1 stars 1 forks source link

Updates to method #2

Open PragTob opened 2 months ago

PragTob commented 2 months ago

Hey there,

thanks a lot for this benchmark and the work you did - it helped me avoid going with Hammer x its ETS in a project :tada:

Over at my fork I did a bunch of changes, most likely not all of which you'd want: https://github.com/PragTob/rate_limit

I guess the most interesting are in https://github.com/PragTob/rate_limit/commit/7a15cf3b5676eb42ccbc31423488c1df93c6c5be - specficially the usage of before_each to get the time for randomly creating the keys out of the benchmark. However, that may not work on your mac as super fast functions in don't play well with hooks (you can thank Mac OSX time resolution for that).

Also helped me find a bug in Benchee (I tried to delete the tables after scenario, but after scenario seemed to trigger multiple times, I suspect due to parallel being configured).

So yeah, just wanted to let you know and say thanks!

ruslandoga commented 2 months ago

👋 @PragTob

Thank you for Benchee!

I wonder what library did you end up choosing?

PragTob commented 2 months ago

@ruslandoga for my current needs I went with plug_attack since just the ETS storage is good enough. Not a fan of the macros but I can live with them. rate_limiter is cool but doesn't clean up the ETS table used and isn't very popular (although atomics are cool). plug_attack also at least has the concept of "storage" so if we wanted to move to multi node rate limiting with redis we could implement it. Also helps that Michał is a trusted friend and that plug_attack was often fastest in my benchmarks with our scenario :)