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 upplever 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 såsom fördröjd databehandling, 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 uppleva begränsningar:
Resursbegränsningar för logikappar
Azure Logic Apps har sina egna dataflödesgränser. Om logikappresursen överskrider dessa gränser begränsas logikappens resurs, 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-portalen.
På resursmenyn för logikappen 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öses som standard flera instanser av den utlösaren 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 talet genom att aktivera utlösarens samtidighetsinställning och vid behov välja en annan gräns än standardvärdet.
Aktivera läge för högt dataflöde.
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 hur många åtgärder som kan köras under ett intervall.
Inaktivera beteendet för matrisbatching eller "Split On" 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 delad.
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 enda objekt per anrop.
Omstrukturera åtgärder till flera, mindre arbetsflöden.
Som tidigare nämnts är ett arbetsflöde för förbrukningslogikapp 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 även ö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 ligger 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 datauppsättningar eller som startar så många åtgärder som körs samtidigt, loop-iterationer eller åtgärder i varje loop-iteration som överskrider gränsen för åtgärdskörning.
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 anslutningsprogram
Varje anslutningsapp har sina egna begränsningar, som du hittar på varje anslutningsapps tekniska referenssida. Azure Service Bus-anslutningsappen har till exempel 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å arbetsflöde för förbrukning 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örbrukningslogikappen i Azure Logic Apps med flera klientorganisationer sker begränsning på anslutningsnivå .
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.
Fundera på 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 loopar 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 loopar 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))I följande exempel på arbetsflöde för förbrukning visas hur du kan använda dessa uttryck:
Konfigurera en annan anslutning för varje åtgärd.
Fundera på 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 samtidigheten eller parallelliteten 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änsningsgränser. Vissa API:er i Microsoft Exchange Server har till exempel strängare begränsningsgränser än Office 365 Outlook-anslutningsappen.
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 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 får 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 skär | 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 (tidigare 5 + 15 nya) |
| T + 1 sekund | 20 skär | 5 fel 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 SQL Server-exempelscenariot 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 enda ö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" så kan du minska 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 uppfylls 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 webhook-versionerna 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 vanligt 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 prenumerationstid 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.