@max904-github possibility of Bucket4j usage in this case highly depends from the answer to the following question:
what is rate and how it should be calculated. Because it is obvious that you can not reduce thing that can not be measured and understood.
If rate can be undestood as X request per Y time-window that it is possible to use Bucket4j in this case in the following way:
Hello @milos01 ,
You can achieve this by:
Doing both steps above allows achieving explicitly that you want. But I am not sure that you need to go in this way. If I have understood correctly you requirements the semaphore will be fully enough for your use case https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Semaphore.html
I do not think that we need to do something if the requests are well distributed over keys, in that case, we can let IDMG do its job. The worst case is the case when all requests are associated with a single(or very few amount of keys), for that case I've implemented several optimizations in the 5.0 branch, but I do not think that you really need to configure this optimization because as you described above there is no single bucket that will act as a bottleneck.
Optimizations were implemented in the
5.0 branch which was not officially released yet. Source code can be found there https://github.com/vladimir-bukhtoyarov/bucket4j/tree/5.0/bucket4j-core/src/main/java/io/github/bucket4j/distributed/proxy/optimization
There are three types of optimizations:
General facts about optimizations:
5.0.0-beta.01-09-2020has been deployed to the maven central https://mvnrepository.com/artifact/com.github.vladimir-bukhtoyarov/bucket4j-core/5.0.0-beta.01-09-2020
5.0branch, because documentation is in progress.
Also the unit tests by itself can be a good explanation of optimization loggic:
And do not forget to configure the listener in order to get proofs whether the optimization is helpful or not for your case
In your tests and during development were you able to come up with some statistics on what can be the expected delay imposed on a system as a function of the number of keys used? Assuming enough shards such that the probability of making a network call is high.
It depends on the particular IDMG provider and the capacity of the cluster. For example, on my production, I have an average latency close to 1,5ms with a request rate clost to 15000 requests per second(but requests are well distributed).
Also interesting to know is what the affect on such a sytem if one or two keys of it are accessed much more excessively than all the rest
It is obvious that high contentions on the same key lead to serious performance degradation. In my experience all IDMG are not able to process more then 1000 requests per second on the same key.
@hderms in few words: Bucket4j uses EntryProcessor behind. One call to bucket equals to one execution of EntryProcessor. You can read about entry processors there https://hazelcast.com/blog/an-easy-performance-improvement-with-entryprocessor/
Also following links can be useful: