Thread und Ratelimiter

[OnDemand]

Hallo zusamen,

wir nutzen einen RateLimiter von Google glaube Guava heisst der.

Angenommen der wird mit 2 initialisiert.

this.rateLimiter = RateLimiter.create(2);

An anderer Stelle erstellen wir einen TaskExecutor mit 20 Threads und müssen da den Ratelimiter nutzen um die Ratelimits des Zielsystems nicht zu überschreiten.

ExecutorService taskExecutor = Executors.newFixedThreadPool(threads);
taskExecutor.execute(() -> {
    sendApi(ratelimiter); //der vorher initailisierte Ratelimiter
});
 try {
         taskExecutor.shutdown();
          taskExecutor.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS);
 } catch (InterruptedException e) {
          e.printStackTrace();
 }

Verstehe ich es richtig dass der Ratelimiter die Threads ausbremst? Also es erstellt zwar 20 Threads aber sendet eben nur so, dass es innerhalb der Ratelimits bleibt?
Soweit ich es nachforsche, ist der Ratelimiter threadsafe.

Wenn ich also mehr parallel auf die API ausspielen will, muss auch das Ratelimite erhöht werden?

 

[httpdigest]

Korrekt.
Alle acquire() Aufrufe auf _derselben_ RateLimiter Instanz führen dazu, dass der RateLimiter die Aufrufer blockiert (bzw. die Aufrufer-Threads warten lässt), um das Limit nicht zu reißen. Es spielt also keine Rolle, mit wievielen Threads du _denselben_ RateLimiter aufrufst.

 

[OnDemand]

Tip top danke

Heisst also:

Angenommen das Zielsystem sagt max 2 Aufrufe pro Sekunde.

Ich befeuere den aber mit 100 Threads, dann managed der Ratelimiter, dass wir die 2 Aufrufe pro Sek. einhalten?

 

[httpdigest]

Heisst also:
Angenommen das Zielsystem sagt max 2 Aufrufe pro Sekunde.
Ich befeuere den aber mit 100 Threads, dann managed der Ratelimiter, dass wir die 2 Aufrufe pro Sek. einhalten?

Genau.

 

[httpdigest]

Ich hatte in einem Projekt auch mal den Guava RateLimitier für genau sowas verwendet. Das Problem bei uns war dabei nur, dass der RateLimiter aufgrund seines thread-basierten Designs "Back Pressure" nur nach vorne kommunizieren kann, indem er die Threads einfach schlafenlegt.
Das Problem hierbei ist, wenn man z.B. seine Anwendungsarchitektur auf non-blocking (z.B. mit Flux/Reactor oder Vert.x) ausgelegt hat. Dann blockiert der eine und möglicherweise einzige Worker Thread.
Wenn man mit non-blocking arbeitet, dann bieten aber Frameworks wie z.B. Reactor aber selber auch Mechanismen.