Throttling in Microsoft Fabric

Microsoft Fabric past capaciteitsbeperking toe om de prestaties en betrouwbaarheid van de service te waarborgen wanneer workloads de capaciteits- of aanvraaglimieten van de REST API overschrijden. In dit artikel wordt uitgelegd hoe throttling werkt, hoe u HTTP 429-reacties moet interpreteren en hoe u toepassingen ontwerpt die effectief omgaan met Fabric API-quota.

API-quotumlimieten

Microsoft Fabric introduceert Unified Quota voor REST API's voor de REST API's. Bij dit model vallen API-aanvragen onder quota op identiteitsniveau, die per gebruiker of Service Principal worden afgedwongen.

Het doel is een consistente, voorspelbare ervaring met verkeersbeperking voor de beheerde API-groepen, voor automatisering, CI/CD en agentgestuurde scenario's.

Voorheen heeft elke Microsoft Fabric REST API zijn eigen onafhankelijke beperkingsregels afgedwongen, wat vaak resulteert in inconsistent gedrag tussen eindpunten. Als gevolg hiervan was het moeilijk om te voorspellen wanneer een workload mogelijk wordt beperkt, met name voor automatiseringsscenario's die interactie hadden met meerdere API's en waarvoor verschillende limieten gelden.

Met de introductie van API's quota gaat Fabric over op een consistentere benadering op basis van identiteiten. API-verbruik wordt nu beheerd door een uniform quotum dat per identiteit wordt afgedwongen, waardoor een duidelijker en beter voorspelbaar beperkingsmodel wordt geboden voor Fabric API's. Het is echter belangrijk om op te merken dat sommige afzonderlijke API-specifieke snelheidslimieten nog steeds van toepassing kunnen zijn, boven op het algemene API-quotum.

Wanneer een API-referentiepagina een quotum documenteert, behandelt u die eindpuntspecifieke limiet als gezaghebbend voor die API. Als op een API-referentiepagina geen numeriek quotum wordt vermeld, ontwerp uw toepassing dan zo dat deze 429-reacties kan verwerken door Retry-After te respecteren, een begrensd aantal nieuwe pogingen toe te passen en verkeerspieken te vermijden.

Hoe het quotamodel werkt

Aan elke identiteit, een gebruiker of een service-principal, worden meerdere onafhankelijke quotumbuckets toegewezen die verschillende categorieën API-verkeer beheren. Wanneer de identiteit een aanvraag verzendt, wordt de aanvraag geëvalueerd op basis van het quotum voor de API-categorie die wordt gebruikt.

Er zijn drie geünificeerde quota:

1. Uniform quotum voor platform-API's — speciaal voor platform-API's.
2. Gecombineerd quotum voor Job Scheduler-API's — specifiek voor Job Scheduler-API's.
3. Geünificeerd quotum voor Long-Running Operations-API's — specifiek voor Long-Running Operations-API's.

Omdat deze quota onafhankelijk zijn, verbruikt activiteit in de ene categorie geen quotum van een andere categorie. Een service-principal kan bijvoorbeeld het volledige geïntegreerde quotum voor Job Scheduler-API's gebruiken zonder dat dit van invloed is op het beschikbare geïntegreerde quotum voor platform-API's. Deze scheiding zorgt ervoor dat werkbelastingen met grote volumes in gespecialiseerde API-domeinen geen invloed hebben op algemene API-bewerkingen en maakt voorspelbaarder snelheidsbeperkingsgedrag mogelijk voor verschillende typen verzoeken.

API-handhaving

Het API-quotum wordt per identiteit afgedwongen, wat betekent dat elke gebruiker, service-principal of beheerde identiteit een eigen onafhankelijke quotatoewijzing ontvangt. Quota worden nooit gedeeld tussen identiteiten en alle in aanmerking komende Fabric API's verbruiken vanuit een gemeenschappelijke quotumbucket die aan die identiteit is gekoppeld.

Als gevolg hiervan heeft API-gebruik door één identiteit geen invloed op een andere identiteit. Een intensief gebruikte service-principal kan bijvoorbeeld de quota van zijn eigen API’s uitputten zonder de quota van andere gebruikers of applicaties te beïnvloeden.

Als een identiteit de quotumlimiet bereikt en wordt beperkt, is die beperking alleen van toepassing op die identiteit, terwijl andere identiteiten normaal blijven werken. Deze isolatie biedt voorspelbaar en beheerbaar API-verbruik voor workloads.

Hiërarchie voor het afdwingen van quota

Elke API-aanvraag begint met een identiteit: een gebruikersaccount of een service-principal. Wanneer deze identiteit een Fabric API aanroept, verbruikt de aanvraag eerst capaciteit van het gedeelde API-quotum, dat wordt afgedwongen per identiteit in plaats van per API. Dit quotum fungeert als een gecentraliseerd beperkingsmechanisme dat wordt gedeeld in alle deelnemende API's, zodat één identiteit de toegewezen aanvraagsnelheid niet kan overschrijden.

Nadat de aanvraag is geëvalueerd op basis van het quotum voor gedeelde API's, worden eventuele API-specifieke beperkingslimieten ook toegepast. Deze limieten zijn onafhankelijk van het gedeelde quotum en kunnen alleen bestaan voor bepaalde API's. Als gevolg hiervan moet een aanvraag voldoen aan zowel het API-quotum op identiteitsniveau als alle toepasselijke afzonderlijke API-limieten die moeten worden verwerkt.

In de praktijk biedt het quotum voor gedeelde API's een consistente beperkingservaring voor API's, terwijl afzonderlijke API-limieten specifieke services blijven beveiligen waarvoor extra beveiliging is vereist. Een API-aanroep kan daarom worden beperkt omdat de identiteit het gedeelde quotum heeft uitgeput of omdat deze de limiet van een bepaald API-eindpunt heeft bereikt.

Sleutelbegrippen:

• Afdwinging op basis van identiteit: Quotum wordt afzonderlijk bijgehouden voor elke gebruiker of service-principal.
• Gedeeld tussen API's: aanvragen aan verschillende API's verbruiken uit dezelfde API-quotumpool.
• Alleen snelheidsbeperking: het API-quotum regelt aanvraagfrequenties, maar heeft geen invloed op autorisatie of machtigingen.
• Dubbele afdwinging: zowel het quotum voor gedeelde API's als eventuele API-specifieke limieten worden geëvalueerd voor elke aanvraag.
• De meeste beperkende limiet wint: een aanvraag wordt beperkt wanneer het gedeelde quotum of een toepasselijke API-specifieke limiet wordt overschreden.

Hoe quotum wordt verbruikt

Elke API-aanvraag verbruikt quotum uit de quotabucket voor API's van de aanroepende identiteit. Alle aanvragen van die identiteit tellen mee voor hetzelfde gedeelde quotum, ongeacht welke API wordt aangeroepen.

Quotumvenster en vernieuwing

Het API-quotum wordt gehandhaafd via een vast tijdvenster van 60 seconden. Het quotum wordt in één keer opnieuw aangevuld wanneer het huidige tijdvenster eindigt. Het quotum wordt binnen het venster niet geleidelijk aangevuld.

Tijdlijnvoorbeeld

Second 0   → Quota window begins. Bucket is full (300 requests available).
Second 1   → 300 requests are made. Bucket is exhausted.
             Additional requests receive HTTP 429 (Too Many Requests).

Seconds 2-59 → All additional requests continue to receive HTTP 429.
               No quota is restored during the window.

Second 60  → New quota window begins.
             Bucket is fully replenished (300 requests available).
             Requests are accepted again.

Praktische implicaties

• Bursting-aanvragen aan het begin van een venster zijn toegestaan, maar hierdoor kan de identiteit voor de rest van dat venster worden beperkt.
• Door aanvragen gelijkmatig over een periode van 60 seconden te verdelen voorkomt u throttling.
• Respecteer altijd de Retry-After-responseheader. Dit geeft aan hoe lang moet worden gewacht voordat een aanvraag waarvoor een snelheidsbeperking geldt, opnieuw wordt geprobeerd.

Details van frequentielimiet per API

Hoewel Microsoft Fabric geïntegreerde beperkingscategorieën en gedeelde quotumconcepten biedt, kunnen de werkelijke frequentielimieten per API variëren. Controleer altijd de sectie 'Throttling limits' voor de API die u aanroept.

Snelheidsbeperkingsbericht

Wanneer snelheidsbeperking optreedt, geeft Fabric de HTTP-statuscode 429 (Te veel aanvragen) terug. Fabric retourneert een 429-statuscode om twee verschillende redenen, die elk zijn geïdentificeerd door een andere errorCode in de antwoordtekst:

• Snelheidslimiet overschreden (RequestBlocked)
• Capaciteitslimiet overschreden (CapacityLimitExceeded)

Inspecteer de errorCode waarde in het antwoord om te bepalen welke voorwaarde is opgetreden en hoe moet worden gereageerd.

Frequentielimiet overschreden (RequestBlocked)

Wanneer een gebruiker veel aanvragen verzendt die een vooraf vastgestelde limiet gedurende een periode overschrijden, beperkt Fabric verdere aanvragen van die gebruiker gedurende een korte periode.

In dit geval retourneert Fabric een HTTP-statuscode 429 (Te veel aanvragen) met een Retry-After HTTP-header in het antwoord, waarmee wordt aangegeven hoeveel seconden de aanroepende toepassing moet wachten voordat de aanroep opnieuw wordt uitgevoerd. De hoofdtekst van het antwoord gebruikt de RequestBlocked foutcode:

{
    "errorCode": "RequestBlocked",
    "message": "Request is blocked by the upstream service until: 2/18/2026 10:45:04 PM (UTC)"
}

Wanneer u deze fout ontvangt, wacht u op de duur die is opgegeven in de Retry-After header voordat u de aanvraag opnieuw probeert.

In de volgende schermopname ziet u een voorbeeld van een antwoord, waarin wordt voorgesteld dat de gebruiker 55 seconden wacht voordat de oproep opnieuw wordt uitgevoerd.

Capaciteitslimiet overschreden (CapacityLimitExceeded)

Fabric retourneert ook een HTTP-statuscode 429 (te veel aanvragen) wanneer de Fabric capaciteit van uw organisatie de limieten heeft overschreden. In tegenstelling tot snelheidsbeperking wordt deze beperking niet veroorzaakt door het aantal API-aanroepen dat een specifieke aanroeper doet. In plaats daarvan gebeurt dit wanneer de rekenkracht (capaciteitseenheden) die voor uw capaciteit worden verbruikt, de limieten van de aangeschafte Fabric-SKU overschrijdt. De hoofdtekst van het antwoord gebruikt de CapacityLimitExceeded foutcode:

{
    "errorCode": "CapacityLimitExceeded",
    "message": "Your organization's Fabric compute capacity has exceeded its limits. Try again later."
}

Wanneer u deze fout ontvangt, probeert u de aanvraag later opnieuw. Omdat deze begrenzing afhangt van het totale rekenverbruik van uw capaciteit en niet van uw eigen aanvraagfrequentie, zal een onmiddellijke nieuwe poging waarschijnlijk niet slagen totdat het rekengebruik van de capaciteit weer binnen de limieten valt. Als u deze fout regelmatig tegenkomt, kunt u overwegen om uw Fabric capaciteit omhoog of uit te schalen. Zie Capaciteitsgrootte plannen voor meer informatie over capaciteitseenheden, SKU's en hoe Fabric capaciteit wordt verbruikt.

Overwegingen en beperkingen

Elke Fabric-beheerder en elke openbare kern-API kan worden beperkt in snelheid.

Houd rekening met deze overwegingen wanneer u toepassingen ontwerpt die Fabric REST API's aanroepen:

• Quota's worden toegepast op basis van de identiteit van de aanroeper en de aangeroepen API. Afzonderlijke identiteiten delen niet noodzakelijkerwijs dezelfde aanvraagteller, maar elke aanroeper moet nog steeds de gedocumenteerde limieten voor de API volgen.
• Veel frequentielimieten worden geëvalueerd in meer dan één minuut. Als u een limiet overschrijdt, wacht u op de Retry-After waarde voordat u meer aanvragen verzendt.
• Capaciteitsbeperking verschilt van aanvraagsnelheidbeperking. CapacityLimitExceededgeeft aan dat de Fabric capaciteit overbelast is, niet dat de aanroeper een API-quotum per minuut heeft overschreden.
• Het is onwaarschijnlijk dat het opnieuw proberen van een capaciteitsbeperkingsfout onmiddellijk lukt. Gebruik een begrensd retrybeleid en onderzoek het capaciteitsgebruik als de fout blijft optreden.
• Voor integraties met grote volumes geeft u de voorkeur aan lijst-, bulk- of batchbewerkingen wanneer ze beschikbaar zijn, cachemetagegevens die niet vaak worden gewijzigd en verspreidt u aanvragen gelijkmatig over een bepaalde periode.
• Voor API's die paginering ondersteunen, gebruikt u vervolgtokens in plaats van herhaalde brede query's vanaf het begin te maken.

Veelgestelde vragen

Hoe weet ik of ik een API-quotum of een capaciteitslimiet heb bereikt?

Controleer de errorCode in de hoofdtekst van het 429-antwoord. RequestBlocked betekent dat de aanvraagsnelheid de beperkingslimieten van de service heeft overschreden. CapacityLimitExceededbetekent dat de verbruikte rekenkracht op de Fabric capaciteit de limieten van de aangeschafte SKU heeft overschreden.

Wanneer wordt mijn quotum opnieuw ingesteld?

Veel Fabric REST API-frequentielimieten worden geëvalueerd over vensters van één minuut. Als het antwoord een Retry-After header bevat, gebruikt u deze waarde als gezaghebbende wachttijd voordat u het opnieuw probeert.

Kan ik mijn resterende API-quotum controleren voordat ik een aanvraag indien?

Fabric REST API-antwoorden bieden geen algemeen teller voor resterende quota voor alle API's. Bouw clients zo dat ze 429-responses kunnen detecteren, rekening houden met Retry-After, en het aantal aanvragen kunnen verminderen wanneer snelheidsbeperking wordt toegepast.

Hoe kan ik de kans verkleinen dat ik word afgeknepen?

Gebruik bulk- en batchbewerkingen indien beschikbaar, geef de voorkeur aan lijst-API's boven veel afzonderlijke aanroepen voor één resource, sla veelgebruikte metagegevens op in de cache en vermijd plotselinge pieken in het verkeer. Voor permanente capaciteitsbeperking gebruikt u de app Microsoft Fabric Capacity Metrics om overbelaste capaciteiten en workloads te identificeren.

Moet ik elke 429-reactie op dezelfde manier opnieuw proberen?

No. Wacht voor RequestBlocked op de Retry-After-header en probeer het vervolgens opnieuw met een beleid met een begrensd aantal nieuwe pogingen. Probeer het voor CapacityLimitExceeded later opnieuw met exponentiële back-off en onderzoek de capaciteitsbenutting als het probleem aanhoudt.

Verwante inhoud

• De REST API's van Microsoft Fabric gebruiken
• Omvang
• Problemen met Microsoft Fabric REST API's oplossen
• De capaciteitsgrootte plannen
• Inzicht in capaciteitsbeperking in Fabric
• Microsoft Fabric Capacity Metrics app