Beperkingsproblemen afhandelen (429 - Fouten met te veel aanvragen) in Azure Logic Apps
Van toepassing op: Azure Logic Apps (Verbruik + Standard)
Als de werkstroom van uw logische app wordt beperkt, wat gebeurt wanneer het aantal aanvragen de snelheid overschrijdt waarmee de bestemming gedurende een bepaalde tijd kan worden verwerkt, krijgt u de fout 'HTTP 429 Te veel aanvragen'. Beperking kan problemen veroorzaken, zoals vertraagde gegevensverwerking, verminderde prestatiesnelheid en fouten zoals het overschrijden van het opgegeven beleid voor opnieuw proberen.
De volgende SQL Server-actie in een werkstroom Verbruik toont bijvoorbeeld een 429-fout, die een beperkingsprobleem meldt:
In de volgende secties worden de algemene niveaus beschreven waarop uw werkstroom beperkingen kan ondervinden:
Resourcebeperking voor logische apps
Azure Logic Apps heeft zijn eigen doorvoerlimieten. Als uw logische app-resource deze limieten overschrijdt, wordt de resource van de logische app beperkt, niet alleen een specifiek werkstroomexemplaren of wordt deze uitgevoerd.
Volg deze stappen om beperkingsevenementen op dit niveau te vinden:
Open uw logische app-resource in Azure Portal.
Selecteer in het resourcemenu van de logische app onder Bewaking de optie Metrische gegevens.
Selecteer onder Grafiektitel de optie Metrische waarde toevoegen, waarmee een andere metrische balk aan de grafiek wordt toegevoegd.
Selecteer in de eerste metrische balk, in de lijst Metrische gegevens, actiebeperkingsgebeurtenissen. Selecteer Aantal in de lijst Aggregatie.
Selecteer in de tweede metrische balk, in de lijst met metrische gegevens, triggergebeurtenissen. Selecteer Aantal in de lijst Aggregatie.
In de grafiek ziet u nu beperkte gebeurtenissen voor zowel acties als triggers in uw werkstroom voor logische apps. Zie Metrische gegevens weergeven voor werkstroomstatus en -prestaties in Azure Logic Apps voor meer informatie.
Als u beperking op dit niveau wilt afhandelen, hebt u de volgende opties:
Beperk het aantal werkstroomexemplaren dat tegelijkertijd kan worden uitgevoerd.
Als aan de triggervoorwaarde van uw werkstroom meer dan één keer tegelijk wordt voldaan, worden meerdere exemplaren van die trigger geactiveerd en gelijktijdig of parallel uitgevoerd. Elke triggerinstantie wordt geactiveerd voordat het vorige werkstroomexemplaren zijn uitgevoerd.
Hoewel het standaardaantal triggerexemplaren dat gelijktijdig kan worden uitgevoerd onbeperkt is, kunt u dit aantal beperken door de gelijktijdigheidsinstelling van de trigger in te schakelen en indien nodig een andere limiet dan de standaardwaarde te selecteren.
Schakel de modus voor hoge doorvoer in.
Een werkstroom Verbruik heeft een standaardlimiet voor het aantal acties dat kan worden uitgevoerd gedurende een doorlopend interval van 5 minuten. Als u deze limiet wilt verhogen tot het maximum aantal acties, schakelt u de modus voor hoge doorvoer in op de resource van uw logische app.
Een standaardwerkstroom heeft geen limiet voor het aantal acties dat tijdens een interval kan worden uitgevoerd.
Schakel het gedrag van matrixdebatching of Split On uit in triggers.
Als een trigger een matrix retourneert voor de resterende werkstroomacties die moeten worden verwerkt, verdeelt de instelling Splitsen bij van de trigger de matrixitems en start een werkstroomexemplaren voor elk matrixitem. Dit gedrag activeert effectief meerdere gelijktijdige uitvoeringen tot de limiet splitsen op.
Als u de beperking wilt beheren, schakelt u het gedrag Splitsen op van de trigger uit en verwerkt u de hele matrix met één aanroep in plaats van één item per aanroep af te handelen.
Herstructureer acties in meerdere, kleinere werkstromen.
Zoals eerder vermeld, is een werkstroom voor logische apps verbruik beperkt tot een standaardaantal acties dat gedurende een periode van vijf minuten kan worden uitgevoerd. Hoewel u deze limiet kunt verhogen door de modus voor hoge doorvoer in te schakelen, kunt u ook overwegen of u de acties van uw werkstroom wilt opsplitsen in kleinere werkstromen, zodat het aantal acties dat in elke werkstroom wordt uitgevoerd, onder de limiet blijft. Op die manier vermindert u de belasting van één werkstroom en distribueert u de belasting over meerdere werkstromen. Deze oplossing werkt beter voor acties die grote gegevenssets verwerken of zo veel gelijktijdig uitgevoerde acties, herhalingen herhalen of acties binnen elke lusiteratie overschrijden die de uitvoeringslimiet van de actie overschrijden.
De volgende werkstroom Verbruik doet bijvoorbeeld al het werk om tabellen op te halen uit een SQL Server-database en haalt de rijen uit elke tabel op. De lus Voor elke lus doorloopt gelijktijdig elke tabel, zodat de actie Rijen ophalen de rijen voor elke tabel retourneert. Op basis van de hoeveelheden gegevens in deze tabellen, kunnen deze acties de limiet voor actie-uitvoeringen overschrijden.
Na herstructurering wordt de oorspronkelijke werkstroom gesplitst in een bovenliggende werkstroom en een onderliggende werkstroom.
De volgende bovenliggende werkstroom haalt de tabellen op uit SQL Server en roept vervolgens de onderliggende werkstroom aan voor elke tabel om de rijen op te halen:
De volgende onderliggende werkstroom wordt aangeroepen door de bovenliggende werkstroom om de rijen voor elke tabel op te halen:
Beperking van verbindingslijn
Elke connector heeft een eigen beperkingslimiet, die u kunt vinden op de technische naslagpagina van elke connector. De Azure Service Bus-connector heeft bijvoorbeeld een beperkingslimiet die maximaal 6000 aanroepen per minuut toestaat, terwijl de SQL Server-connector beperkingen heeft die variëren op basis van het bewerkingstype.
Sommige triggers en acties, zoals HTTP, hebben een beleid voor opnieuw proberen dat u kunt aanpassen op basis van de beleidslimieten voor opnieuw proberen om uitzonderingsafhandeling te implementeren. Dit beleid geeft aan of en hoe vaak een trigger of actie een aanvraag opnieuw probeert wanneer de oorspronkelijke aanvraag mislukt of een time-out optreedt en resulteert in een 408-, 429- of 5xx-antwoord. Dus wanneer beperking wordt gestart en een 429-fout wordt geretourneerd, volgt Logic Apps het beleid voor opnieuw proberen, waar ondersteund.
Als u wilt weten of een trigger of actie beleid voor opnieuw proberen ondersteunt, controleert u de instellingen van de trigger of actie. Als u de nieuwe pogingen van een trigger of actie wilt bekijken, gaat u naar de uitvoeringsgeschiedenis van uw logische app, selecteert u de uitvoering die u wilt controleren en vouwt u die trigger of actie uit om details over invoer, uitvoer en eventuele nieuwe pogingen weer te geven.
In het volgende voorbeeld van een verbruikswerkstroom ziet u waar u deze informatie kunt vinden voor een HTTP-actie:
Hoewel de geschiedenis van opnieuw proberen foutinformatie biedt, kan het lastig zijn om onderscheid te maken tussen connectorbeperking en doelbeperking. In dit geval moet u mogelijk de details van het antwoord controleren of een aantal berekeningen voor beperkingsinterval uitvoeren om de bron te identificeren.
Voor werkstromen van logische apps voor verbruik in multitenant Azure Logic Apps vindt beperking plaats op verbindingsniveau.
Als u beperking op dit niveau wilt afhandelen, hebt u de volgende opties:
Stel meerdere verbindingen in voor één actie, zodat de werkstroom de gegevens voor verwerking kan partitioneren.
Overweeg of u de werkbelasting kunt distribueren door de aanvragen van een actie over meerdere verbindingen met dezelfde bestemming te verdelen met behulp van dezelfde referenties.
Stel dat uw werkstroom tabellen ophaalt uit een SQL Server-database en vervolgens de rijen uit elke tabel ophaalt. Op basis van het aantal rijen dat u moet verwerken, kunt u meerdere verbindingen en meerdere voor elke lussen gebruiken om het totale aantal rijen te verdelen in kleinere sets voor verwerking. In dit scenario worden twee voor elke lussen gebruikt om het totale aantal rijen in de helft te splitsen. De eerste voor elke lus maakt gebruik van een expressie die de eerste helft ophaalt. De andere voor elke lus maakt gebruik van een andere expressie die de tweede helft ophaalt, bijvoorbeeld:
Expressie 1: De
take()functie haalt de voorkant van een verzameling op. Zie detake()functie voor meer informatie.@take(collection-or-array-name, div(length(collection-or-array-name), 2))Expressie 2: De
skip()functie verwijdert de voorzijde van een verzameling en retourneert alle andere items. Zie deskip()functie voor meer informatie.@skip(collection-or-array-name, div(length(collection-or-array-name), 2))In het volgende voorbeeld van de werkstroom Verbruik ziet u hoe u deze expressies kunt gebruiken:
Stel een andere verbinding in voor elke actie.
Overweeg of u de workload kunt distribueren door de aanvragen van elke actie over hun eigen verbinding te spreiden, zelfs wanneer acties verbinding maken met dezelfde service of hetzelfde systeem en dezelfde referenties gebruiken.
Stel dat uw werkstroom de tabellen ophaalt uit een SQL Server-database en elke rij in elke tabel ophaalt. U kunt afzonderlijke verbindingen gebruiken, zodat de ophalen van de tabellen één verbinding gebruikt, terwijl voor het ophalen van elke rij een andere verbinding wordt gebruikt.
In het volgende voorbeeld ziet u een verbruikswerkstroom die voor elke actie een andere verbinding maakt en gebruikt:
Wijzig de gelijktijdigheid of parallelle uitvoering van een lus voor elke lus.
Standaard worden herhalingen voor elke lus op hetzelfde moment uitgevoerd tot aan de gelijktijdigheidslimiet. Als u een verbinding hebt die wordt beperkt binnen een lus voor elke lus, kunt u het aantal herhalende herhalingen verminderen dat parallel wordt uitgevoerd. Voor meer informatie raadpleegt u de volgende documentatie:
Doelservice of systeembeperking
Hoewel een connector zijn eigen beperkingslimieten heeft, kan de doelservice of het systeem dat door de connector wordt aangeroepen, ook beperkingslimieten hebben. Sommige API's in Microsoft Exchange Server hebben bijvoorbeeld strengere beperkingslimieten dan de Office 365 Outlook-connector.
Standaard worden de werkstroomexemplaren van een logische app en eventuele lussen of vertakkingen binnen deze exemplaren parallel uitgevoerd. Dit gedrag betekent dat meerdere exemplaren hetzelfde eindpunt tegelijkertijd kunnen aanroepen. Elk exemplaar weet niet over het bestaan van de andere, dus pogingen om mislukte acties opnieuw uit te voeren, kunnen racevoorwaarden creëren waarbij meerdere aanroepen tegelijkertijd proberen uit te voeren, maar om te slagen, moeten deze aanroepen aankomen bij de doelservice of het systeem voordat de beperking begint te gebeuren.
Stel dat u een matrix hebt met 100 items. U gebruikt een lus 'Voor elke' om de matrix te doorlopen en het gelijktijdigheidsbeheer van de lus in te schakelen, zodat u het aantal parallelle iteraties kunt beperken tot 20 of de huidige standaardlimiet. Binnen die lus wordt met een actie een item uit de matrix ingevoegd in een SQL Server-database, die slechts 15 aanroepen per seconde toestaat. Dit scenario resulteert in een beperkingsprobleem omdat een achterstand van nieuwe pogingen wordt opgebouwd en nooit wordt uitgevoerd.
In de volgende tabel wordt de tijdlijn beschreven voor wat er in de lus gebeurt wanneer het interval voor opnieuw proberen van de actie 1 seconde is:
| Tijdstip | Aantal acties dat wordt uitgevoerd | Aantal acties dat mislukt | Aantal nieuwe pogingen wachten |
|---|---|---|---|
| T + 0 seconden | 20 invoegingen | 5 mislukken vanwege sql-limiet | 5 nieuwe pogingen |
| T + 0,5 seconden | 15 invoegingen, vanwege eerdere 5 nieuwe pogingen die wachten | Alle 15 mislukken, omdat de eerdere SQL-limiet nog steeds van kracht is voor nog eens 0,5 seconden | 20 nieuwe pogingen (vorige 5 + 15 nieuwe) |
| T + 1 seconde | 20 invoegingen | 5 mislukt plus eerdere 20 nieuwe pogingen, vanwege de SQL-limiet | 25 nieuwe pogingen (vorige 20 + 5 nieuwe) |
Als u beperking op dit niveau wilt afhandelen, hebt u de volgende opties:
Afzonderlijke werkstromen maken zodat elke werkstroom één bewerking afhandelt.
Als u doorgaat met het voorbeeldscenario van SQL Server in deze sectie, kunt u een werkstroom maken waarmee matrixitems in een wachtrij worden geplaatst, zoals een Azure Service Bus-wachtrij. Vervolgens maakt u een andere werkstroom waarmee alleen de invoegbewerking voor elk item in die wachtrij wordt uitgevoerd. Op die manier wordt slechts één werkstroomexemplaren op een bepaald moment uitgevoerd, waardoor de invoegbewerking wordt voltooid en naar het volgende item in de wachtrij wordt verplaatst, of krijgt het exemplaar 429 fouten, maar probeert geen onproductieve nieuwe pogingen uit te voeren.
Maak een bovenliggende werkstroom die een onderliggende of geneste werkstroom aanroept voor elke actie. Als het bovenliggende item verschillende onderliggende werkstromen moet aanroepen op basis van het resultaat van het bovenliggende item, kunt u een voorwaardeactie gebruiken of een andere actie gebruiken waarmee wordt bepaald welke onderliggende werkstroom moet worden aangeroepen. Met dit patroon kunt u het aantal oproepen of bewerkingen verminderen.
Stel dat u twee werkstromen hebt, elk met een poll-trigger waarmee uw e-mailaccount elke minuut wordt gecontroleerd op een specifiek onderwerp, zoals Geslaagd of Mislukt. Deze instelling resulteert in 120 aanroepen per uur. Als u in plaats daarvan één bovenliggende werkstroom maakt die elke minuut pollt, maar een onderliggende werkstroom aanroept die wordt uitgevoerd op basis van of het onderwerp 'Geslaagd' of 'Mislukt' is, knipt u in dit geval het aantal pollingcontroles naar de helft of 60.
Batchverwerking instellen. (Alleen werkstromen voor verbruik)
Als de doelservice batchbewerkingen ondersteunt, kunt u beperking aanpakken door items in groepen of batches te verwerken in plaats van afzonderlijk. Als u de oplossing voor batchverwerking wilt implementeren, maakt u een werkstroom voor logische apps voor batchontvanger en een werkstroom voor logische apps met batch-afzenders. De batchzender verzamelt berichten of items totdat aan uw opgegeven criteria wordt voldaan en verzendt deze berichten of items vervolgens in één groep. De batchontvanger accepteert die groep en verwerkt deze berichten of items. Zie Batch-berichten in groepen verwerken voor meer informatie.
Gebruik de webhookversies voor triggers en acties in plaats van de pollingversies.
Waarom? Een polling-trigger blijft de doelservice of het systeem controleren met specifieke intervallen. Een zeer frequent interval, zoals elke seconde, kan beperkingsproblemen veroorzaken. Een webhooktrigger of -actie, zoals HTTP-webhook, maakt echter slechts één aanroep naar de doelservice of het doelsysteem, die op het moment van het abonnement plaatsvindt en vraagt dat de bestemming de trigger of actie alleen opgeeft wanneer een gebeurtenis plaatsvindt. Op die manier hoeft de trigger of actie de bestemming niet voortdurend te controleren.
Dus als de doelservice of het systeem webhooks ondersteunt of een connector met een webhookversie biedt, is deze optie beter dan het gebruik van de polling-versie. Als u webhooktriggers en -acties wilt identificeren, controleert u of ze het
ApiConnectionWebhooktype hebben of dat u geen terugkeerpatroon hoeft op te geven. Zie apiConnectionWebhook-trigger en APIConnectionWebhook-actie voor meer informatie.