Hantera begränsningsproblem (429 – "För många begäranden"-fel) i Azure Logic Apps
Gäller för: Azure Logic Apps (Förbrukning + Standard)
Om arbetsflödet för logikappen har begränsningar, vilket inträffar när antalet begäranden överskrider den hastighet som målet kan hantera under en viss tid, får du felet "HTTP 429 För många begäranden". Begränsning kan skapa problem som fördröjd databearbetning, minskad prestandahastighet och fel som att överskrida den angivna återförsöksprincipen.
Följande SQL Server åtgärd i ett förbrukningsarbetsflöde visar till exempel ett 429-fel som rapporterar ett begränsningsproblem:
I följande avsnitt beskrivs de vanliga nivåer där arbetsflödet kan få begränsningar:
Resursbegränsning för logikappen
Azure Logic Apps har sina egna dataflödesgränser. Om logikappresursen överskrider dessa gränser begränsas logikappresursen, inte bara en specifik arbetsflödesinstans eller körning.
Följ dessa steg för att hitta begränsningshändelser på den här nivån:
Öppna logikappresursen i Azure Portal.
På logikappens resursmeny går du till Övervakning och väljer Mått.
Under Diagramrubrik väljer du Lägg till mått, vilket lägger till ytterligare ett måttfält i diagrammet.
I det första måttfältet går du till listan Mått och väljer Åtgärdsbegränsningshändelser. I listan Sammansättning väljer du Antal.
I det andra måttfältet går du till listan Mått och väljer Utlösarbegränsningshändelser. I listan Sammansättning väljer du Antal.
Diagrammet visar nu begränsade händelser för både åtgärder och utlösare i logikappens arbetsflöde. Mer information finns i Visa mått för arbetsflödets hälsa och prestanda i Azure Logic Apps.
För att hantera begränsningar på den här nivån har du följande alternativ:
Begränsa antalet arbetsflödesinstanser som kan köras samtidigt.
Om arbetsflödets utlösarvillkor uppfylls mer än en gång samtidigt utlöser flera instanser av det som utlöses som standard och körs samtidigt eller parallellt. Varje utlösarinstans utlöses innan den tidigare arbetsflödesinstansen har körts.
Även om standardantalet för utlösarinstanser som kan köras samtidigt är obegränsat kan du begränsa det här antalet genom att aktivera utlösarens samtidighetsinställning och vid behov välja en annan gräns än standardvärdet.
Aktivera högt dataflödesläge.
Ett förbrukningsarbetsflöde har en standardgräns för antalet åtgärder som kan köras under ett rullande intervall på 5 minuter. Om du vill höja den här gränsen till det maximala antalet åtgärder aktiverar du läget för högt dataflöde på logikappresursen.
Ett Standard-arbetsflöde har ingen gräns för antalet åtgärder som kan köras under ett intervall.
Inaktivera matrisbatching eller "Split On"-beteende i utlösare.
Om en utlösare returnerar en matris för återstående arbetsflödesåtgärder som ska bearbetas, delar utlösarens inställning Split On upp matrisobjekten och startar en arbetsflödesinstans för varje matrisobjekt. Det här beteendet utlöser effektivt flera samtidiga körningar upp till gränsen för delning.
Om du vill kontrollera begränsningen inaktiverar du utlösarens Beteende för delning på och får arbetsflödet att bearbeta hela matrisen med ett enda anrop, i stället för att hantera ett enskilt objekt per anrop.
Omstrukturera åtgärder till flera, mindre arbetsflöden.
Som tidigare nämnts är arbetsflödet för logikappen Förbrukning begränsat till ett standardantal åtgärder som kan köras under en femminutersperiod. Även om du kan öka den här gränsen genom att aktivera läget för högt dataflöde kan du också överväga om du vill dela upp arbetsflödets åtgärder i mindre arbetsflöden så att antalet åtgärder som körs i varje arbetsflöde förblir under gränsen. På så sätt minskar du belastningen på ett enda arbetsflöde och distribuerar belastningen över flera arbetsflöden. Den här lösningen fungerar bättre för åtgärder som hanterar stora datamängder eller som startar så många åtgärder som körs samtidigt, loop-iterationer eller åtgärder i varje loop-iteration som överskrider åtgärdskörningsgränsen.
Följande arbetsflöde för förbrukning utför till exempel allt arbete för att hämta tabeller från en SQL Server databas och hämtar raderna från varje tabell. För varje loop itererar samtidigt genom varje tabell så att åtgärden Hämta rader returnerar raderna för varje tabell. Baserat på mängden data i dessa tabeller kan dessa åtgärder överskrida gränsen för åtgärdskörningar.
Efter refaktorisering delas det ursprungliga arbetsflödet upp i ett överordnat arbetsflöde och ett underordnat arbetsflöde.
Följande överordnade arbetsflöde hämtar tabellerna från SQL Server och anropar sedan det underordnade arbetsflödet för varje tabell för att hämta raderna:
Följande underordnade arbetsflöde anropas av det överordnade arbetsflödet för att hämta raderna för varje tabell:
Begränsning av anslutningsapp
Varje anslutningsapp har sina egna begränsningsgränser, som du hittar på varje anslutningsapps tekniska referenssida. Till exempel har Azure Service Bus-anslutningsappen en begränsningsgräns som tillåter upp till 6 000 anrop per minut, medan SQL Server-anslutningsappen har begränsningar som varierar beroende på åtgärdstyp.
Vissa utlösare och åtgärder, till exempel HTTP, har en "återförsöksprincip" som du kan anpassa baserat på begränsningarna för återförsöksprinciper för att implementera undantagshantering. Den här principen anger om och hur ofta en utlösare eller åtgärd försöker skicka en begäran igen när den ursprungliga begäran misslyckas eller överskrider tidsgränsen och resulterar i ett svar på 408, 429 eller 5xx. Så när begränsningen startar och returnerar ett 429-fel följer Logic Apps återförsöksprincipen där det stöds.
Om du vill veta om en utlösare eller åtgärd stöder återförsöksprinciper kontrollerar du inställningarna för utlösaren eller åtgärden. Om du vill visa en utlösare eller åtgärds återförsök går du till logikappens körningshistorik, väljer den körning som du vill granska och expanderar utlösaren eller åtgärden för att visa information om indata, utdata och eventuella återförsök.
I följande exempel på förbrukningsarbetsflöde visas var du hittar den här informationen för en HTTP-åtgärd:
Även om återförsökshistoriken innehåller felinformation kan du ha problem med att skilja mellan anslutningsbegränsning och målbegränsning. I det här fallet kan du behöva granska svarets information eller utföra vissa beräkningar för begränsningsintervall för att identifiera källan.
För arbetsflöden för förbrukningslogikappar i Azure Logic Apps för flera klientorganisationer sker begränsningen på anslutningsnivå . För logikapparbetsflöden som körs i en integrationstjänstmiljö (ISE) sker begränsning fortfarande för icke-ISE-anslutningar eftersom de körs i Azure Logic Apps för flera klientorganisationer. ISE-anslutningar, som skapas av ISE-anslutningsappar, begränsas dock inte eftersom de körs i din ISE.
För att hantera begränsningar på den här nivån har du följande alternativ:
Konfigurera flera anslutningar för en enda åtgärd så att arbetsflödet kan partitioneras data för bearbetning.
Överväg om du kan distribuera arbetsbelastningen genom att dela upp en åtgärds begäranden mellan flera anslutningar till samma mål med samma autentiseringsuppgifter.
Anta till exempel att arbetsflödet hämtar tabeller från en SQL Server databas och sedan hämtar raderna från varje tabell. Baserat på antalet rader som du måste bearbeta kan du använda flera anslutningar och flera För varje loop för att dela upp det totala antalet rader i mindre uppsättningar för bearbetning. Det här scenariot använder två för varje loop för att dela det totala antalet rader i hälften. Den första för varje loop använder ett uttryck som hämtar den första halvan. Den andra för varje loop använder ett annat uttryck som hämtar den andra halvan, till exempel:
Uttryck 1: Funktionen
take()hämtar framsidan av en samling. Mer information finns itake()funktionen .@take(collection-or-array-name, div(length(collection-or-array-name), 2))Uttryck 2: Funktionen
skip()tar bort framsidan av en samling och returnerar alla andra objekt. Mer information finns iskip()funktionen .@skip(collection-or-array-name, div(length(collection-or-array-name), 2))Följande exempel på förbrukningsarbetsflöde visar hur du kan använda dessa uttryck:
Konfigurera en annan anslutning för varje åtgärd.
Överväg om du kan distribuera arbetsbelastningen genom att sprida varje åtgärds begäranden via sin egen anslutning, även när åtgärder ansluter till samma tjänst eller system och använder samma autentiseringsuppgifter.
Anta till exempel att arbetsflödet hämtar tabellerna från en SQL Server databas och hämtar varje rad i varje tabell. Du kan använda separata anslutningar så att hämtar tabellerna använder en anslutning, medan hämtar varje rad använder en annan anslutning.
I följande exempel visas ett förbrukningsarbetsflöde som skapar och använder en annan anslutning för varje åtgärd:
Ändra samtidighet eller parallellitet i en "För varje"-loop.
Som standard körs "För varje" loop-iterationer samtidigt upp till samtidighetsgränsen. Om du har en anslutning som begränsas i en "För varje"-loop kan du minska antalet loop-iterationer som körs parallellt. Mer information finns i följande dokumentation:
Måltjänst eller systembegränsning
Även om en anslutningsapp har sina egna begränsningsgränser kan måltjänsten eller systemet som anropas av anslutningsappen också ha begränsningar. Vissa API:er i Microsoft Exchange Server till exempel ha strängare begränsningsgränser än Office 365 Outlook-anslutningsprogrammet.
Som standard körs en logikapps arbetsflödesinstanser och eventuella loopar eller grenar i dessa instanser parallellt. Det här beteendet innebär att flera instanser kan anropa samma slutpunkt samtidigt. Varje instans känner inte till den andres existens, så försök att försöka utföra misslyckade åtgärder på nytt kan skapa konkurrensvillkor där flera anrop försöker köras samtidigt, men för att lyckas måste dessa anrop komma fram till måltjänsten eller systemet innan begränsningen börjar ske.
Anta till exempel att du har en matris som har 100 objekt. Du använder en "För varje"-loop för att iterera genom matrisen och aktivera loopens samtidighetskontroll så att du kan begränsa antalet parallella iterationer till 20 eller den aktuella standardgränsen. I den loopen infogar en åtgärd ett objekt från matrisen i en SQL Server databas, vilket endast tillåter 15 anrop per sekund. Det här scenariot resulterar i ett begränsningsproblem eftersom en eftersläpning av återförsök byggs upp och aldrig kommer att köras.
I följande tabell beskrivs tidslinjen för vad som händer i loopen när åtgärdens återförsöksintervall är 1 sekund:
| Tidpunkt | Antal åtgärder som körs | Antal åtgärder som misslyckas | Antal återförsök som väntar |
|---|---|---|---|
| T + 0 sekunder | 20 infogningar | 5 misslyckas på grund av SQL-gräns | 5 återförsök |
| T + 0,5 sekunder | 15 infogningar, på grund av tidigare 5 återförsök väntar | Alla 15 misslyckas på grund av att den tidigare SQL-gränsen fortfarande gäller i ytterligare 0,5 sekunder | 20 återförsök (föregående 5 + 15 nya) |
| T + 1 sekund | 20 infogningar | 5 misslyckas plus tidigare 20 återförsök på grund av SQL-gräns | 25 återförsök (tidigare 20 + 5 nya) |
För att hantera begränsningar på den här nivån har du följande alternativ:
Skapa enskilda arbetsflöden så att var och en hanterar en enda åtgärd.
Om du fortsätter med exemplet SQL Server scenariot i det här avsnittet kan du skapa ett arbetsflöde som placerar matrisobjekt i en kö, till exempel en Azure Service Bus kö. Sedan skapar du ett annat arbetsflöde som endast utför infogningsåtgärden för varje objekt i kön. På så sätt körs bara en arbetsflödesinstans vid en viss tidpunkt, vilket antingen slutför infogningsåtgärden och går vidare till nästa objekt i kön, eller så får instansen 429 fel men försöker inte utföra improduktiva återförsök.
Skapa ett överordnat arbetsflöde som anropar ett underordnat eller kapslat arbetsflöde för varje åtgärd. Om den överordnade användaren behöver anropa olika underordnade arbetsflöden baserat på det överordnade resultatet kan du använda en villkorsåtgärd eller växla åtgärd som avgör vilket underordnat arbetsflöde som ska anropas. Det här mönstret kan hjälpa dig att minska antalet anrop eller åtgärder.
Anta till exempel att du har två arbetsflöden, var och en med en avsökningsutlösare som kontrollerar ditt e-postkonto varje minut för ett specifikt ämne, till exempel "Lyckades" eller "Fel". Den här konfigurationen resulterar i 120 anrop per timme. Om du i stället skapar ett enskilt överordnat arbetsflöde som avsöker varje minut men anropar ett underordnat arbetsflöde som körs baserat på om ämnet är "Lyckades" eller "Fel" minskar du antalet avsökningskontroller till hälften eller 60 i det här fallet.
Konfigurera batchbearbetning. (Endast förbrukningsarbetsflöden)
Om måltjänsten stöder batchåtgärder kan du hantera begränsningar genom att bearbeta objekt i grupper eller batchar i stället för individuellt. Om du vill implementera batchbearbetningslösningen skapar du ett logikapparbetsflöde för "batchmottagare" och ett logikapparbetsflöde för "batch-avsändare". Batch-avsändaren samlar in meddelanden eller objekt tills dina angivna villkor har uppfyllts och skickar sedan dessa meddelanden eller objekt i en enda grupp. Batchmottagaren accepterar den gruppen och bearbetar dessa meddelanden eller objekt. Mer information finns i Batch-processmeddelanden i grupper.
Använd webhookens versioner för utlösare och åtgärder i stället för avsökningsversionerna.
Varför? En avsökningsutlösare fortsätter att kontrollera måltjänsten eller systemet med specifika intervall. Ett mycket frekvent intervall, till exempel varje sekund, kan skapa begränsningsproblem. En webhook-utlösare eller -åtgärd, till exempel HTTP Webhook, skapar dock bara ett enda anrop till måltjänsten eller systemet, vilket sker vid prenumerationstillfället och begär att målet endast meddelar utlösaren eller åtgärden när en händelse inträffar. På så sätt behöver utlösaren eller åtgärden inte kontinuerligt kontrollera målet.
Så om måltjänsten eller systemet stöder webhooks eller tillhandahåller en anslutningsapp som har en webhook-version är det här alternativet bättre än att använda avsökningsversionen. Om du vill identifiera webhook-utlösare och åtgärder kontrollerar du att de har
ApiConnectionWebhooktypen eller att de inte kräver att du anger en upprepning. Mer information finns i APIConnectionWebhook-utlösare och APIConnectionWebhook-åtgärd.