Hvad betyder Rate limiting?
Rate limiting styrer belastningen på et system. En tjeneste kan begrænse kald pr. sekund, tokens pr. minut eller samtidige opgaver. Begrænsningen kan gælde en bruger, en konto, et endpoint eller en samlet installation.
For AI-løsninger påvirker det både svartid og kapacitet. En enkelt brugerhandling kan udløse flere model- og værktøjskald, så antallet af brugere alene ikke beskriver belastningen. En robust integration skal kende de relevante grænser og planlægge arbejdet, før de nås.
Fordel arbejdet efter den reelle begrænsning
En kø kan udjævne spidsbelastning, mens en begrænsning af samtidighed holder antallet af aktive opgaver nede. Disse mekanismer er forskellige: få samtidige, meget hurtige kald kan stadig overskride en grænse pr. sekund. Mål derfor både hyppighed, samtidighed og den enhed, udbyderen tæller.
Hvis tjenesten afviser med HTTP 429, kan den give en Retry-After-anvisning. Klienten bør følge den dokumenterede politik og bruge kontrollerede genforsøg. At sende mere trafik i håb om at komme igennem kan gøre situationen værre for både egen og andres behandling.
Beskyt vigtige opgaver og vis ventetid
Fordel kapaciteten bevidst mellem interaktive opgaver og baggrundsarbejde. En stor import bør ikke nødvendigvis bruge hele budgettet, mens kunder venter på svar. Definér en maksimal køalder og en forståelig status for forsinkede opgaver. Højere abonnement eller kvote løser ikke automatisk et uhensigtsmæssigt kaldemønster. Undersøg først gentagne opslag, manglende caching og unødvendige parallelle trin. Kapacitetsplanen bør også tage højde for, at fejlsituationer kan skabe ekstra genforsøg.
Et eksempel fra praksis
En virksomhed importerer produktbeskrivelser til en AI-vidensbase. I stedet for at sende alle filer samtidigt lægges de i en kø med afgrænset behandling. Interaktive kundespørgsmål har separat plads i budgettet. Testen indfører en lav grænse og undersøger, om systemet bevarer alle opgaver, viser ventestatus og genoptager uden dubletter. Det er bedre end blot at kontrollere, at en lille testfil kunne behandles.
Typiske faldgruber
- At forveksle antal samtidige opgaver med antal kald pr. tidsenhed.
- At lade baggrundsarbejde bruge hele kapaciteten til interaktive svar.
- At håndtere kapacitetsfejl med hurtige, ubegrænsede genforsøg.
Det skal I afklare
- Kortlæg begrænsningens enhed, niveau og dokumenterede fejlsvar.
- Styr kø, samtidighed og prioritet hver for sig.
- Test spidsbelastning og mål køalder samt fuldførte opgaver.
Spørgsmål og svar
Er rate limiting kun en fejltilstand?
Nej. Det er en normal beskyttelsesmekanisme. En velbygget klient kan tilpasse sin trafik og vise ventetid, så begrænsningen ikke fører til tabte eller dublerede opgaver.
Betyder HTTP 429, at intet er sket?
Det konkrete endpoint skal afgøre det. Klienten bør følge tjenestens dokumentation og bruge sikker genforsøgslogik. Generelt er det vigtigt at skelne mellem afvist trafik og et usikkert udfald efter tidsudløb.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- IETF: RFC 6585 ↗HTTP 429 og den valgfrie Retry-After-anvisning.
- Google Cloud: Retry strategy ↗Eksponentiel ventetid, tilfældig variation og idempotens.