Beperkingsproblemen afhandelen (429 - fouten met te veel aanvragen) in Azure Logic Apps
Van toepassing op: Azure Logic Apps (verbruik + standaard)
Als de werkstroom van uw logische app beperkingen ondervindt, wat gebeurt wanneer het aantal aanvragen de snelheid overschrijdt waarmee de bestemming gedurende een bepaalde tijd kan verwerken, 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 eigen doorvoerlimieten. Als de resource van uw logische app deze limieten overschrijdt, wordt de resource van uw logische app beperkt, niet alleen een specifiek werkstroomexemplaar of een specifieke uitvoering.
Voer de volgende stappen uit om beperkingsevenementen op dit niveau te vinden:
Open in de Azure Portal de resource van uw logische app.
Selecteer in het resourcemenu van de logische app onder Bewakingde 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 gegevensde optie Actie vertraagde gebeurtenissen. Selecteer Aantal in de lijst Aggregatie.
Selecteer in de tweede metrische balk in de lijst Metrische gegevensde optie Beperkte gebeurtenissen activeren. Selecteer Aantal in de lijst Aggregatie.
De grafiek toont nu beperkte gebeurtenissen voor zowel acties als triggers in de werkstroom van uw logische app. 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 er standaard meerdere exemplaren van die trigger geactiveerd en gelijktijdig of parallel uitgevoerd. Elk triggerexemplaar wordt geactiveerd voordat het vorige werkstroomexemplaar is 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 verbruikswerkstroom heeft een standaardlimiet voor het aantal acties dat kan worden uitgevoerd gedurende een voortschrijdend interval van vijf minuten. Als u deze limiet wilt verhogen naar het maximum aantal acties, schakelt u de modus voor hoge doorvoer in op uw logische app-resource.
Een standaardwerkstroom heeft geen limiet voor het aantal acties dat tijdens een interval kan worden uitgevoerd.
Schakel matrixdiscussiching of Split On-gedrag in triggers uit.
Als een trigger een matrix retourneert voor de resterende werkstroomacties die moeten worden verwerkt, worden met de instelling Splitsen aan van de trigger de matrixitems verdeeld en wordt een werkstroomexemplaar voor elk matrixitem gestart. Dit gedrag activeert in feite meerdere gelijktijdige uitvoeringen tot de limiet splitsen aan.
Als u beperking wilt beheren, schakelt u het splitsgedrag van de trigger uit en laat u uw werkstroom de hele matrix verwerken met één aanroep, in plaats van één item per aanroep te verwerken.
Acties herstructureren in meerdere, kleinere werkstromen.
Zoals eerder vermeld, is een werkstroom voor de logische app 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 verdeelt u de belasting over meerdere werkstromen. Deze oplossing werkt beter voor acties die grote gegevenssets verwerken of zo veel gelijktijdig uitgevoerde acties, herhalingen of acties binnen elke lus-iteratie uitvoeren dat ze de limiet voor de uitvoering 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 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.
Met de volgende bovenliggende werkstroom worden de tabellen opgehaald uit SQL Server en wordt vervolgens de onderliggende werkstroom voor elke tabel aangeroepen 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:
Connectorbeperking
Elke connector heeft zijn eigen beperkingslimieten, die u kunt vinden op de pagina met technische naslaginformatie van elke connector. De Azure Service Bus-connector heeft bijvoorbeeld een beperkingslimiet die maximaal 6000 aanroepen per minuut toestaat, terwijl de SQL Server-connector beperkingslimieten 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 de verwerking van uitzonderingen 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, indien 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 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 de verbruikswerkstroom ziet u waar u deze informatie voor een HTTP-actie kunt vinden:
Hoewel de geschiedenis van nieuwe pogingen 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 enkele beperkingsintervalberekeningen uitvoeren om de bron te identificeren.
Voor verbruikswerkstromen voor logische apps in Azure Logic Apps met meerdere tenants vindt beperking plaats op verbindingsniveau . Voor werkstromen van logische apps die worden uitgevoerd in een Integration Service Environment (ISE) vindt beperking nog steeds plaats voor niet-ISE-verbindingen, omdat deze worden uitgevoerd in azure logic apps met meerdere tenants. ISE-verbindingen, die worden gemaakt door ISE-connectors, worden echter niet beperkt omdat ze in uw ISE worden uitgevoerd.
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 kan partitioneren voor verwerking.
Overweeg of u de workload kunt distribueren door de aanvragen van een actie te verdelen over meerdere verbindingen met dezelfde bestemming met 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 For each-lussen gebruiken om het totale aantal rijen te verdelen over kleinere sets voor verwerking. In dit scenario worden twee For each-lussen gebruikt om het totale aantal rijen in tweeën te splitsen. De eerste For each-lus maakt gebruik van een expressie die de eerste helft ophaalt. De andere For each-lus gebruikt 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 voorkant 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 verbruikswerkstroom ziet u hoe u deze expressies kunt gebruiken:
Stel voor elke actie een andere verbinding in.
Overweeg of u de workload kunt distribueren door de aanvragen van elke actie te spreiden over hun eigen verbinding, 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 tabellen die de tabellen ophalen één verbinding gebruiken, terwijl de ophaalt elke rij een andere verbinding gebruikt.
In het volgende voorbeeld ziet u een verbruikswerkstroom die voor elke actie een andere verbinding maakt en gebruikt:
Wijzig de gelijktijdigheid of parallellisme in een 'Voor elke'-lus.
Standaard worden herhalingen van de 'For each'-lus op hetzelfde moment uitgevoerd tot de gelijktijdigheidslimiet. Als u een verbinding hebt die wordt beperkt binnen een 'Voor elke'-lus, kunt u het aantal lusiteraties verminderen dat parallel wordt uitgevoerd. Zie de volgende documentatie voor meer informatie:
Doelservice- of systeembeperking
Hoewel een connector eigen beperkingslimieten heeft, heeft de doelservice of het doelsysteem dat door de connector wordt aangeroepen, mogelijk ook beperkingslimieten. 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 die exemplaren parallel uitgevoerd. Dit gedrag betekent dat meerdere exemplaren hetzelfde eindpunt tegelijkertijd kunnen aanroepen. Elk exemplaar is niet op de hoogte van het bestaan van de ander, dus pogingen om mislukte acties opnieuw uit te voeren, kunnen racevoorwaarden creëren waarbij meerdere aanroepen tegelijkertijd worden uitgevoerd, maar om te slagen, moeten deze aanroepen binnenkomen bij de doelservice of het systeem voordat de beperking begint.
Stel dat u een matrix hebt met 100 items. U gebruikt een 'For each'-lus 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 voegt een actie een item uit de matrix in een SQL Server-database in, waardoor slechts 15 aanroepen per seconde mogelijk zijn. Dit scenario resulteert in een beperkingsprobleem omdat er 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 dat wacht |
|---|---|---|---|
| T + 0 seconden | 20 invoegingen | 5 mislukken vanwege SQL-limiet | 5 nieuwe pogingen |
| T + 0,5 seconden | 15 inserts, vanwege eerdere 5 nieuwe pogingen die wachten | Alle 15 mislukken, omdat de vorige SQL-limiet nog 0,5 seconden van kracht is | 20 nieuwe pogingen (vorige 5 + 15 nieuw) |
| T + 1 seconde | 20 invoegingen | 5 mislukken plus eerdere 20 nieuwe pogingen vanwege SQL-limiet | 25 nieuwe pogingen (vorige 20 + 5 nieuwe) |
Als u beperking op dit niveau wilt afhandelen, hebt u de volgende opties:
Maak afzonderlijke werkstromen, zodat elke werkstroom één bewerking verwerkt.
Als u verdergaat met het voorbeeld SQL Server scenario 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 die alleen de invoegbewerking voor elk item in die wachtrij uitvoert. Op die manier wordt slechts één werkstroomexemplaar op een bepaald moment uitgevoerd, waardoor de invoegbewerking wordt voltooid en naar het volgende item in de wachtrij wordt verplaatst, of dat het exemplaar 429-fouten krijgt, maar geen onproductieve nieuwe pogingen probeert te doen.
Maak een bovenliggende werkstroom die voor elke actie een onderliggende of geneste werkstroom aanroept. Als het bovenliggende item verschillende onderliggende werkstromen moet aanroepen op basis van het resultaat van het bovenliggende item, kunt u een voorwaardeactie of een schakelactie gebruiken die bepaalt welke onderliggende werkstroom moet worden aangeroepen. Dit patroon kan u helpen het aantal aanroepen of bewerkingen te 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 een poll uitvoert, maar een onderliggende werkstroom aanroept die wordt uitgevoerd op basis van of het onderwerp 'Geslaagd' of 'Mislukt' is, wordt het aantal pollingcontroles gehalvd tot de helft, of in dit geval 60.
Batchverwerking instellen. (Alleen werkstromen voor verbruik)
Als de doelservice batchbewerkingen ondersteunt, kunt u beperkingen oplossen 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 een logische app 'batchontvanger' en een 'batch sender'-werkstroom voor logische apps. De afzender van de batch verzamelt berichten of items totdat aan uw opgegeven criteria is voldaan en verzendt deze berichten of items vervolgens in één groep. De batchontvanger accepteert die groep en verwerkt deze berichten of items. Zie Berichten in groepen in Batch verwerken voor meer informatie.
Gebruik de webhookversies voor triggers en acties in plaats van de pollingversies.
Hoe komt dat? Een pollingtrigger blijft de doelservice of het systeem met specifieke intervallen controleren. Een zeer frequent interval, zoals elke seconde, kan beperkingsproblemen veroorzaken. Met een webhooktrigger of -actie, zoals HTTP-webhook, wordt echter slechts één aanroep naar de doelservice of het doelsysteem gemaakt. Dit gebeurt op het moment van het abonnement en vraagt de bestemming de trigger of actie alleen te informeren wanneer er een gebeurtenis plaatsvindt. Op die manier hoeft de trigger of actie de bestemming niet voortdurend te controleren.
Dus als de doelservice of het doelsysteem 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.