Sinds kort resulteren mijn BAG API requests op status 429 too many requests. Is er onlangs iets veranderd? Zijn er misschien rate limits toegevoegd?
Is er BAG API beleid als het gaat om parallelle streaming searches door gebruikers die resulteren in zwaardere API belasting?
Een 429 krijg je in theorie pas bij meer dan 100 requests per seconde. Ik geloof niet dat daar recent iets aan gewijzigd is, maar zal het maandag nog even controleren.
Officieel beleid over gebruik is er niet echt (zover ik weet). Meeste APIs zijn fair use maar zonder beschrijving van wat dat inhoudt. In de praktijk loop je tegen de rate limiting aan, en wordt een gebruiker gevraagd zijn gebruik aan te passen als het problemen op het backend veroorzaakt.
Misschien kan @sylviaverkleij vertellen of er ergens recente gebruiksvoorwaarden voor de APIs te vinden zijn, of dat deze in de maak zijn.
Voor de zekerheid heb ik mijn recente migraties naar Erlang OTP 24 en httpoison 8.0 teruggedraaid en uitgetest. Maar zonder resultaat. Vaak gaat een falende search na een tijdje weer gewoon goed zonder enige software aanpassing.
Krijg naast de status 429 ook af en toe timeouts. Is er misschien iets veranderd in de routering van jullie gateway naar de BAG API backends?
Heb zojuist nog even de rate-limiting gecontroleerd. Deze staat inderdaad op 100 requests per seconde per gebruiker. Als je daar overheen gaat krijg je een 429.
De timeouts worden waarschijnlijk veroorzaakt door een tekort aan resources voor het backend. Daar kijken we zsm naar.
Net vanmorgen eerst van productie omgeving en vervolgens daarna van testomgeving geprobeerd en zonder problemen. Nu gaat alles volgens verwachting gewoon goed.
Moeten we dit uitzoeken? Vindt er andere belasting plaats onder mijn API key? Gaat er iets fout in de API key matching? Of, was er misschien minder capaciteit beschikbaar wegens onderhoud?
Kan je aangeven wanneer de problemen begonnen? Wat mij betreft is een 429 geen probleem aan onze kant, een timeout wel.
Als je zelf je API key niet gedeeld hebt, is er geen reden om aan te nemen dat er oneigenlijk gebruik van wordt gemaakt.
Voor zover ik kan zien, is er de afgelopen dagen geen onderhoud geweest dat invloed heeft gehad op het functioneren van de BAG API.
Misschien gaat het nu goed omdat er nu tijdens werkdagen weer meer belasting is.
Dit is een timestamp gisteren van een too many requests abort …
Started by John at 2021-06-06 09:57:26 UTC as 8 threads and aborted in 3 min 15 sec.
Kan het misschien zijn dat het systeem in het weekend onbelast is en dat mijn searches daardoor te hard lopen en overvragen? De doorlooptijden van de wel geslaagde searches (nu en in het weekeinde) zijn naar verwachting plus/minus 7-8 minuten. Het vreemde is dat ik hetzelfde probleem had met een search met een enkele thread. Daar zou je het probleem zeker niet verwachten.
Theoretisch zou ik zelf rate limiting moeten implementeren naast de graad van parallellisatie als aantal threads. Praktisch is dat echter tot nog toe nooit een probleem geweest. Kon bij problemen altijd gewoon naar beneden gaan in aantal threads. Dit keer bood dat geen soelaas.
Dat kan zeker. Gemiddeld genomen is het gebruik in het weekend significant lager dan doordeweeks, dus zullen de requests ook iets sneller een respons krijgen.
Gebruiksvoorwaarden gevonden: https://www.pdok.nl/documents/1901824/4016976/PDOK_PDC_AFNEMERS+28-04-2021+v1.pdf
Bevragingen van veel data dient nadrukkelijk via een bulk-download plaats te vinden, […]
Wordt alleen nergens expliciet gemaakt waar de grens tussen “data” en “veel data” ligt.