Hallo zusammen,
der Titel sagt eigentlich alles. Hier ein Beispiel mit einer Rate von 0.1 bzw. 1 Aufruf pro 10 Sekunden.
Gruß
Gustav
Hallo Gustav,
vielen Dank für den Hinweis!
Ich habe das Thema an unsere Entwickler weitergeleitet.
Wir melden uns, sobald es Neuigkeiten gibt.
Viele Grüße
Felix
Hallo Gustav,
das Problem ist jetzt behoben.
Viele Grüße
Felix
1 „Gefällt mir“
Hallo @synesty-Felix,
leider kriege ich bei der Billbee-API weiterhin 429-Errors, wenn ich deren angegebenes Ratelimit von 2 Requests pro Sekunde verwende. Daher habe ich nochmal nachgeforscht. Konnte aber keinen Fehler finden, die Billbee-API ist wohl einfach sehr störisch.
Was mir dabei aber aufgefallen ist: Die Anzeige von der Wartezeit zwischen den einzelnen Aufrufen wird nicht immer angegeben. Gibt es irgendeinen Bedingung von euch, die diese Ausgabe auslöst und nicht immer greift? Ich würde diese Ausgabe immer erwarten, wenn gewartet wird.
Hier in dem Screenshot wird links 1 Request pro Sekunde verwendet. Ohne Limit laufen die 25 Requests innerhalb von 4 Sekunden durch, das Throttling greift also definitiv. Aber warum habe ich hier keine Info über die Wartezeit wie rechts?
Selbes Verhalten auch im SpreadsheetUrlDownload.
Gruß
Gustav
Hallo Gustav,
leider kriege ich bei der Billbee-API weiterhin 429-Errors, wenn ich deren angegebenes Ratelimit von 2 Requests pro Sekunde verwende. Daher habe ich nochmal nachgeforscht. Konnte aber keinen Fehler finden, die Billbee-API ist wohl einfach sehr störisch.
Konntest du das mit dem Absenken des RateLimits lösen?
Was mir dabei aber aufgefallen ist: Die Anzeige von der Wartezeit zwischen den einzelnen Aufrufen wird nicht immer angegeben. Gibt es irgendeinen Bedingung von euch, die diese Ausgabe auslöst und nicht immer greift?
Ja bei uns gibt es eine Bedingung, welche die Wartezeit nur ausgibt, wenn pro Sekunde ein Call oder weniger gemacht werden. Ansonsten würde sich der Log für fast jeden APICall oder SpreadsheetURLDownloader verdoppeln.
Wir werden das intern noch mal besprechen. Ggfs. kann im Fall, dass die Bedingung nicht greift, im Log vor dem ersten Call auf die Wartezeit hingewiesen werden.
Viele Grüße
Felix
Hallo @synesty-Felix,
ich habe einige Step, wo das Limit von 2 Anfragen pro Sekunde funktioniert. Der einzige Schritt, wo es für mich wirklich wichtig ist, dass die Abfragen schnell ablaufen, funktioniert. Daher ist das okay für mich.
Vermute Billbee gefiel einfach meine Weg, viele Aufrufe zu produzieren nicht. Dafür habe ich die Pagesize einfach auf 1 geändert. Das Thema ist erledigt.
Bei dem APICall/SpreadsheetUrldownload irgendein sicheres Feedback haben wäre super. Vielleicht kann man einfach eine Logausgabe am Ende ausgeben, welche die gesamte gewartete Zeit ausgibt?
Gruß
Gustav
Hallo Gustav,
wir haben uns vorerst dazu entschieden, dass eingestellte rate limit nur am Anfang des Steps zu loggen, da die bisherige Logik der Log Ausgabe (Wartezeit des Rate Limiter > 1 Sek.) eher verwirrt hat.
Den Wert könnten wir ausgeben. Wir sind uns noch nicht sicher, welche Werte wirklich interessant.
Wäre gesamte Wartezeit oder die durchschnittliche Wartezeit besser? Wäre die benötigte Zeit für Request/Response auch interessant ? Die Gesamtzeit zwischen den Calls setzt sich grob aus diesen Werten zusammen.
Du kannst uns gern schreiben, wenn du Vorschläge hast. Ansonsten würden wir erstmal die durchschnittliche Wartezeit des Rate Limiters loggen.
VG Torsten
Hallo Torsten,
hatte die Mail noch im Posteingang stecken und nie wegsortiert, weil ich hier irgendwann nochmal eine Antwort schreiben wollte. Besagtes Irgendwann ist wohl jetzt 
.
Primär geht es mir darum, dass die tatsächlichen Wartezeit irgendwie ersichtlich wird. Ich denke, die durchschnittliche Wartezeit und durchschnittliche Antwortzeit pro Request wären ein guter Anfang.
Gruß
Gustav