Spring Boot Limits API calls

[OnDemand]

Hallo zusammen,

mit RestTemplate SpringBoot rufe ich eine API die max 2 Anfragen pro Minute zulässt zb. ein anderer Enpoint 60 mal pro Minute.

Aktuell handhabe ich es so, dass ich it @Retry auf die Fehlermeldung reagiere, find ich aber irgendwie unpraktisch da zu Abbrüchen kommt. Kann man von vornherein irgendwie die Limits einhalten ohne dass man erst reagiert wenn die API "Too many connections" zurück gibt?

 

[Flown]

Ich denke nach was du suchst sind Stichworte: "spring boot service throttle"

 

[OnDemand]

suuuper danke 🙂 man muss nur wissen wnach macn googln muss danke =)

 

[OnDemand]

Hmm das will irgendwie nicht :

RateLimiter rateLimiterGetProducts = RateLimiter.create(1);
rateLimiterGetProducts.acquire(1);
//call API

die API lässt 60 Aufrufe pro min zu. Geht auch komischerweise ein paar Minuten, dann nicht mehr. Ich vermute, dass die API da einen Fehler hat

 

[LimDul]

Kommt der Aufruf der API direkt hinter dem acquire? Oder wird da noch mehr Code gemacht? Ich würde den auch nicht auf 1 setzen, sondern knapp drüber (z.B. 1.1).

Den der RateLimiter limitiert ja nicht den Aufruf der API - sondern sagt "Die Codezeile kann einmal pro Sekunde durchlaufen werden". Bis dann wirklich der Request abgesendet und bei der API aufschlägt vergeht ja auch etwas Zeit, da muss ggf. eine TCP/IP Verbindung aufgebaut werden etc. - Das dauert nicht bei jedem Aufruf gleich lang, so dass es sein kann dass du mal 61 Aufrufe in innerhalb von 60 Sekunden hast, weil halt der erste der 61 Aufrufe 10ms gedauert hat, bis der den API-Call abgeschickt hat und die nächsten 60 haben nur 5ms Sekunden gedauert.

 

[OnDemand]

Jupp der API Call kommt direkt nach dem .aquire()

Wir haben jetzt mal einen Test gemacht und die API 60 mal aufgerufen, dafür haben wir aber 2 Minuten gebraucht. Trotzdem kam die Meldung, dass das Limit erreicht wurde. Daher tippe ich mal drauf, dass die externe API falsch ist oder deren Doku nicht stimmt.

 

[OnDemand]

Ein anderer API Endpoint sagt max 1 Aufrud pro 6 Minuten, wir kann ich das denn lösen?
RateLimiter rateLimiter= RateLimiter.create(1/360) ? (360 sek = 6 min)

 

[LimDul]

Solange du keine Integer Division da verwendest sollte es eigentlich gehen 🙂

 

[mihe7]

Hmm das will irgendwie nicht :

RateLimiter rateLimiterGetProducts = RateLimiter.create(1);
rateLimiterGetProducts.acquire(1);
//call API

die API lässt 60 Aufrufe pro min zu. Geht auch komischerweise ein paar Minuten, dann nicht mehr. Ich vermute, dass die API da einen Fehler hat

Blöde Frage: Du erzeugst aber nicht zufällig bei jedem Aufruf einen neuen RateLimiter? 🙂

 

[Flown]

So OT Diskussion: HIER

 

[mrBrown]

Wenn du Spring Boot nutzt, kannst du resilience4j ziemlich einfach nutzen.

Methode entsprechende annotieren, in den Properties das Limit für den jeweiligen Endpoint hinerlegen und fertig.

 

[OnDemand]

Das klappt Mit dem Guava RateLimiter super. Für spätere Besucher die ein ähnliches Problem haben: wichtig ist wie @LimDul sagt, dass man keine Integer Division macht. Statt

private RateLimiter rateLimiterGetAuthToken = RateLimiter.create(1 / 360);

muss man

private RateLimiter rateLimiterGetAuthToken = RateLimiter.create(1.0 / 360.0);

 

[OnDemand]

Bin hier noch auf was gestoßen, dass ich mir nicht erklären kann.

Ich hole mir einen Token und bekomme als Antwort folgendes:

{"token":"eyJ0e-Ei7X3Tgo","valid_until":1618067803}

Dann prüfe ich wie folgt, ob der token noch gültig ist:

public boolean isTokenExpired() {
     return !Instant.now().isBefore(tokenExpires);
}

Klappt auch. Wenn der Token dann ungültig ist hole ich einen neuen, bekomme aber 429 too many requests. Das kann ich mir so gar nicht erklären weil ich definitiv das Limit nicht überschreite.

Einen neuen token darf man nur 1 mal in 6 Minuten holen, der Token gilt dann für 20 Minuten. Die Zeiten in Klammern, ist die Zeit aus der Response in GMT (ich bin in CEST) kann es damit was zu tun haben? Aber die uhr tickt doch überall gleich schnell^^

1. Token holen: 17:15:03 (Token bekommen 15:15:03 GMT)
neuer token gültig bis 2021-04-10T15:35:03Z also 20 min

2. Token abgelaufen: 17:35:05
Hole neuen Token: und bekomme 429 mit Response Zeitpunkt 15:35:06 GMT
Im Header steht ausserdem: X-RateLimit-Remaining:"0", Retry-After:"50"

Könnte also in 50 sek nochmal versuchen. Versteh ich aber nicht weil ja die 6 min laange um sind.

Hat jemand ne Idee was da los sein könnte?

Wenn ich es lokal mit Postman mache, kann ich nach 6 min einen Token holen. Auf dem Server klappts nicht, daher meine Vermutung dass es an der Zeitzone liegt. Die hat doch aber damit nix zu tun oder?

Der Ratelimiter schlägt da auch nicht an, da die 6 Minuten ja um sind, logo.

 

[mrBrown]

Lass dir testweise mal jeden Request loggen, nicht dass da einer durchrutscht.

 

[OnDemand]

Ich lass mir bereits alles über einen Interceptor im Resttemplate loggen, sieht auch gut aus. hab auch gedacht, dass ich versehntlich 2 mal den Token anfordere aber ist nicht. Hab auch schon ein total profesionelles sysout rein gemacht beim Methodenaufruf, aber der kommt nur 2 mal (beim initalen anfragen und beim verlängern)

 

[OnDemand]

im gesamten Log taucht der aufgerufene Endpoint wirklich nur 2 mal auf, doppelt ist da nix. Zeitlich auch ausserhalb der 6 Minuten.
Hab das Gefühl, dass die API da irgendwas komisches macht. Die Doku ist nämlich auch falsch (ursprüngliches Problem mit 60/minute ist nämlich 60/5minuten)

 

[OnDemand]

Gibt es vielleicht irgendwas, dass ich mit der API mitsenden muss im Header wovon in der Doku nix steht?! Aber so limits werden doch anhand des Users ausgemacht, der die Anfrage sendet oder? Viellicht nehmen die die IP, mach nämlich kurz bevor der Token abläuft eine andere Anfrage an die API

 

[OnDemand]

Ganz misteriös...
Wenn ich den Aufruf für den Token zb per CURL direkt 2 x hintereinander mache:

lokal: sagt die API retry in 360 sek
auf dem Server: sagt die API retry in 20 min

Was zum kukuk ist das für ein Murks. Da kann doch nur die API abhängig zur IP, andere Limits vorgeben. Wobei meine lokale IP da nicht irgendwie bekannt ist sodass die da andere Limits hinterlegt hätten

 

[OnDemand]

Problem war SSL falls es jemanden interessiert. Bei einem Endpoint hat es mit https andere Limits als ohne SSL.
Warum macht man das? Brauch der "Handshake" so viel mehr Rechenleistung, sodass man die Rate Limits erhöhen muss?

 

[Flown]

Weil die meisten Cloud-Dienste nach CPU/Service Zeit den Preis verrechnen. Nachdem SSL Rechenaufwand bedeutet -> weniger API calls.

 

[OnDemand]

Danke dann macht das Sinn 🙂