Obsługa problemów z ograniczaniem przepustowości (429 — błędy "Zbyt wiele żądań") w usłudze Azure Logic Apps
Dotyczy: Azure Logic Apps (Zużycie + Standardowa)
Jeśli przepływ pracy aplikacji logiki napotyka ograniczanie przepustowości, co występuje, gdy liczba żądań przekracza szybkość, z jaką miejsce docelowe może obsłużyć przez określony czas, zostanie wyświetlony błąd "HTTP 429 Zbyt wiele żądań". Ograniczanie przepustowości może powodować problemy takie jak opóźnione przetwarzanie danych, zmniejszona szybkość wydajności i błędy, takie jak przekroczenie określonych zasad ponawiania.
Na przykład następująca akcja programu SQL Server w przepływie pracy Zużycie pokazuje błąd 429, który zgłasza problem z ograniczaniem przepustowości:
W poniższych sekcjach opisano typowe poziomy, na których może wystąpić ograniczanie przepływów pracy:
Ograniczanie użycia zasobów aplikacji logiki
Usługa Azure Logic Apps ma własne limity przepływności. Jeśli zasób aplikacji logiki przekroczy te limity, zasób aplikacji logiki zostanie ograniczony, a nie tylko określone wystąpienie lub uruchomienie przepływu pracy.
Aby znaleźć zdarzenia ograniczania przepustowości na tym poziomie, wykonaj następujące kroki:
W witrynie Azure Portal otwórz zasób aplikacji logiki.
W menu zasobów aplikacji logiki w obszarze Monitorowanie wybierz pozycję Metryki.
W obszarze Tytuł wykresu wybierz pozycję Dodaj metryki, która dodaje kolejny słupek metryk do wykresu.
Na pierwszym pasku metryk z listy Metryka wybierz pozycję Zdarzenia ograniczone akcji. Z listy Agregacja wybierz pozycję Liczba.
Na drugim pasku metryk z listy Metryka wybierz pozycję Wyzwalaj zdarzenia ograniczone. Z listy Agregacja wybierz pozycję Liczba.
Wykres przedstawia teraz zdarzenia ograniczone dla akcji i wyzwalaczy w przepływie pracy aplikacji logiki. Aby uzyskać więcej informacji, zobacz Wyświetlanie metryk dotyczących kondycji i wydajności przepływu pracy w usłudze Azure Logic Apps.
Aby obsłużyć ograniczanie przepustowości na tym poziomie, dostępne są następujące opcje:
Ogranicz liczbę wystąpień przepływu pracy, które mogą być uruchamiane w tym samym czasie.
Domyślnie, jeśli warunek wyzwalacza przepływu pracy jest spełniony więcej niż raz w tym samym czasie, wiele wystąpień tego wyzwalacza uruchamia i uruchamia jednocześnie lub równolegle. Każde wystąpienie wyzwalacza jest uruchamiane przed zakończeniem działania poprzedniego wystąpienia przepływu pracy.
Chociaż domyślna liczba wystąpień wyzwalacza, które mogą być uruchamiane współbieżnie, jest nieograniczona, można ograniczyć tę liczbę , włączając ustawienie współbieżności wyzwalacza, a w razie potrzeby wybierz limit inny niż wartość domyślna.
Włącz tryb wysokiej przepływności.
Przepływ pracy Zużycie ma domyślny limit liczby akcji, które mogą być uruchamiane w 5-minutowym interwale kroczącym. Aby zwiększyć ten limit do maksymalnej liczby akcji, włącz tryb wysokiej przepływności w zasobie aplikacji logiki.
Przepływ pracy w warstwie Standardowa nie ma limitu liczby akcji, które mogą być uruchamiane w dowolnym interwale.
Wyłącz zachowanie rozdzielania tablic lub "Split On" w wyzwalaczach.
Jeśli wyzwalacz zwraca tablicę dla pozostałych akcji przepływu pracy do przetworzenia, ustawienie Split On wyzwalacza dzieli elementy tablicy i uruchamia wystąpienie przepływu pracy dla każdego elementu tablicy. To zachowanie skutecznie wyzwala wiele współbieżnych uruchomień do limitu podziału na.
Aby kontrolować ograniczanie przepustowości, wyłącz zachowanie split on wyzwalacza i przetwórz całą tablicę z jednym wywołaniem zamiast obsługiwać pojedynczy element na wywołanie.
Refaktoryzacja akcji w wielu, mniejszych przepływach pracy.
Jak wspomniano wcześniej, przepływ pracy aplikacji logiki zużycie jest ograniczony do domyślnej liczby akcji, które mogą być uruchamiane w ciągu 5 minut. Chociaż można zwiększyć ten limit, włączając tryb wysokiej przepływności, możesz również rozważyć, czy chcesz podzielić akcje przepływu pracy na mniejsze przepływy pracy, tak aby liczba akcji uruchamianych w każdym przepływie pracy pozostawała poniżej limitu. Dzięki temu można zmniejszyć obciążenie jednego przepływu pracy i rozłożyć obciążenie między wiele przepływów pracy. To rozwiązanie działa lepiej w przypadku akcji, które obsługują duże zestawy danych lub uruchamiają tak wiele współbieżnych akcji, iteracji pętli lub akcji wewnątrz każdej iteracji pętli, że przekraczają limit wykonywania akcji.
Na przykład poniższy przepływ pracy Zużycie wykonuje całą pracę, aby pobrać tabele z bazy danych programu SQL Server i pobiera wiersze z każdej tabeli. Pętla Dla każdej pętli równoczesnie iteruje po każdej tabeli, aby akcja Pobierz wiersze zwracała wiersze dla każdej tabeli. Na podstawie ilości danych w tych tabelach te akcje mogą przekraczać limit wykonań akcji.
Po refaktoryzacji oryginalny przepływ pracy jest podzielony na nadrzędny przepływ pracy i podrzędny przepływ pracy.
Następujący nadrzędny przepływ pracy pobiera tabele z programu SQL Server, a następnie wywołuje podrzędny przepływ pracy dla każdej tabeli w celu pobrania wierszy:
Następujący podrzędny przepływ pracy jest wywoływany przez nadrzędny przepływ pracy w celu pobrania wierszy dla każdej tabeli:
Ograniczanie przepustowości łącznika
Każdy łącznik ma własne limity ograniczania przepustowości, które można znaleźć na stronie dokumentacji technicznej każdego łącznika. Na przykład łącznik usługi Azure Service Bus ma limit ograniczania, który zezwala na maksymalnie 6000 wywołań na minutę, podczas gdy łącznik programu SQL Server ma limity ograniczania przepustowości, które różnią się w zależności od typu operacji.
Niektóre wyzwalacze i akcje, takie jak HTTP, mają "zasady ponawiania prób" , które można dostosować na podstawie limitów zasad ponawiania w celu zaimplementowania obsługi wyjątków . Te zasady określają, czy i jak często wyzwalacz lub akcja ponawia żądanie, gdy oryginalne żądanie kończy się niepowodzeniem lub limitem czasu, i powoduje odpowiedź 408, 429 lub 5xx. Dlatego w przypadku uruchamiania ograniczania przepustowości i zwraca błąd 429, usługa Logic Apps jest zgodna z zasadami ponawiania, jeśli są obsługiwane.
Aby dowiedzieć się, czy wyzwalacz lub akcja obsługuje zasady ponawiania prób, sprawdź ustawienia wyzwalacza lub akcji. Aby wyświetlić próby ponawiania prób wyzwalacza lub akcji, przejdź do historii przebiegów aplikacji logiki, wybierz przebieg, który chcesz przejrzeć, i rozwiń ten wyzwalacz lub akcję, aby wyświetlić szczegółowe informacje o danych wejściowych, danych wyjściowych i wszelkich ponownych próbach.
Poniższy przykład przepływu pracy Zużycie pokazuje, gdzie można znaleźć te informacje dla akcji HTTP:
Mimo że historia ponawiania zawiera informacje o błędach, może wystąpić problem z różnicą między ograniczaniem przepustowości łącznika a ograniczaniem miejsc docelowych. W takim przypadku może być konieczne przejrzenie szczegółów odpowiedzi lub wykonanie obliczeń interwału ograniczania przepustowości w celu zidentyfikowania źródła.
W przypadku przepływów pracy aplikacji logiki zużycie w wielodostępnych usłudze Azure Logic Apps ograniczanie odbywa się na poziomie połączenia .
Aby obsłużyć ograniczanie przepustowości na tym poziomie, dostępne są następujące opcje:
Skonfiguruj wiele połączeń dla jednej akcji, aby przepływ pracy mógł podzielić dane na partycje na potrzeby przetwarzania.
Zastanów się, czy obciążenie można dystrybuować, dzieląc żądania akcji między wiele połączeń z tym samym miejscem docelowym przy użyciu tych samych poświadczeń.
Załóżmy na przykład, że przepływ pracy pobiera tabele z bazy danych programu SQL Server, a następnie pobiera wiersze z każdej tabeli. Na podstawie liczby wierszy, które należy przetworzyć, można użyć wielu połączeń i wielu dla każdej pętli, aby podzielić łączną liczbę wierszy na mniejsze zestawy do przetwarzania. W tym scenariuszu użyto dwóch pętli Dla każdej pętli, aby podzielić łączną liczbę wierszy w połowie. Pierwsza pętla Dla każdej pętli używa wyrażenia, które pobiera pierwszą połowę. Druga pętla Dla każdej pętli używa innego wyrażenia, które pobiera drugą połowę, na przykład:
Wyrażenie 1.
take()Funkcja pobiera front kolekcji. Aby uzyskać więcej informacji, zobacztake()funkcję .@take(collection-or-array-name, div(length(collection-or-array-name), 2))Wyrażenie 2:
skip()Funkcja usuwa front kolekcji i zwraca wszystkie inne elementy. Aby uzyskać więcej informacji, zobaczskip()funkcję .@skip(collection-or-array-name, div(length(collection-or-array-name), 2))W poniższym przykładzie przepływu pracy Zużycie pokazano, jak można używać tych wyrażeń:
Skonfiguruj inne połączenie dla każdej akcji.
Zastanów się, czy obciążenie można dystrybuować, rozkładając żądania poszczególnych akcji na własne połączenie, nawet jeśli akcje łączą się z tą samą usługą lub systemem i używają tych samych poświadczeń.
Załóżmy na przykład, że przepływ pracy pobiera tabele z bazy danych programu SQL Server i pobiera każdy wiersz w każdej tabeli. Można użyć oddzielnych połączeń, aby pobieranie tabel używało jednego połączenia, podczas gdy pobieranie każdego wiersza używa innego połączenia.
W poniższym przykładzie przedstawiono przepływ pracy Zużycie, który tworzy i używa innego połączenia dla każdej akcji:
Zmień współbieżność lub równoległość w pętli "Dla każdego".
Domyślnie iteracje pętli "Dla każdego" są uruchamiane w tym samym czasie do limitu współbieżności. Jeśli masz połączenie, które jest ograniczane wewnątrz pętli "Dla każdego", możesz zmniejszyć liczbę iteracji pętli uruchamianych równolegle. Więcej informacji można znaleźć w następującej dokumentacji:
Ograniczanie przepustowości usługi docelowej lub systemu
Chociaż łącznik ma własne limity ograniczania przepustowości, usługa docelowa lub system, który jest wywoływany przez łącznik, może również mieć limity ograniczania przepustowości. Na przykład niektóre interfejsy API w programie Microsoft Exchange Server mają bardziej rygorystyczne limity ograniczania przepustowości niż łącznik usługi Office 365 Outlook.
Domyślnie wystąpienia przepływu pracy aplikacji logiki i wszystkie pętle lub gałęzie wewnątrz tych wystąpień są uruchamiane równolegle. To zachowanie oznacza, że wiele wystąpień może jednocześnie wywoływać ten sam punkt końcowy. Każde wystąpienie nie wie o istnieniu innej osoby, więc próby ponawiania próby wykonania akcji, które zakończyły się niepowodzeniem, mogą utworzyć warunki wyścigu, w których wiele wywołań próbuje uruchomić w tym samym czasie, ale aby zakończyć się powodzeniem, te wywołania muszą dotrzeć do usługi docelowej lub systemu przed rozpoczęciem ograniczania przepustowości.
Załóżmy na przykład, że masz tablicę zawierającą 100 elementów. Pętla "Dla każdego" służy do iterowania przez tablicę i włączania kontrolki współbieżności pętli, aby ograniczyć liczbę iteracji równoległych do 20 lub bieżącego limitu domyślnego. Wewnątrz tej pętli akcja wstawia element z tablicy do bazy danych programu SQL Server, która zezwala tylko na 15 wywołań na sekundę. Ten scenariusz powoduje problem z ograniczaniem przepustowości, ponieważ zaległości ponownych prób są kompilujące i nigdy nie są uruchamiane.
W poniższej tabeli opisano oś czasu dla tego, co dzieje się w pętli, gdy interwał ponawiania próby akcji wynosi 1 sekundę:
| Punkt w czasie | Liczba akcji uruchamianych | Liczba akcji zakończonych niepowodzeniem | Liczba ponownych prób oczekiwania |
|---|---|---|---|
| T + 0 sekund | 20 wstawień | 5 nie powiodło się z powodu limitu SQL | 5 ponownych prób |
| T + 0,5 sekundy | 15 wstawień z powodu poprzednich 5 ponownych prób oczekiwania | Wszystkie 15 nie powiodło się, ponieważ poprzedni limit SQL nadal obowiązywał przez kolejne 0,5 sekundy | 20 ponownych prób (poprzednie 5 + 15 nowych) |
| T + 1 sekunda | 20 wstawień | 5 nie powiodło się i poprzednio 20 ponownych prób z powodu limitu SQL | 25 ponownych prób (poprzednie 20 + 5 nowych) |
Aby obsłużyć ograniczanie przepustowości na tym poziomie, dostępne są następujące opcje:
Utwórz poszczególne przepływy pracy, aby każda z nich obsługiwała jedną operację.
Kontynuując przykładowy scenariusz programu SQL Server w tej sekcji, możesz utworzyć przepływ pracy, który umieszcza elementy tablicy w kolejce, na przykład w kolejce usługi Azure Service Bus. Następnie utworzysz kolejny przepływ pracy, który wykonuje tylko operację wstawiania dla każdego elementu w tej kolejce. W ten sposób tylko jedno wystąpienie przepływu pracy jest uruchamiane w dowolnym momencie, co powoduje ukończenie operacji wstawiania i przejście do następnego elementu w kolejce lub wystąpienie pobiera błędy 429, ale nie podejmuje nieprodukcyjnych ponownych prób.
Utwórz nadrzędny przepływ pracy, który wywołuje podrzędny lub zagnieżdżony przepływ pracy dla każdej akcji. Jeśli element nadrzędny musi wywoływać różne podrzędne przepływy pracy na podstawie wyniku elementu nadrzędnego, możesz użyć akcji warunku lub akcji przełączania, która określa, który podrzędny przepływ pracy ma być wywoływany. Ten wzorzec może pomóc zmniejszyć liczbę wywołań lub operacji.
Załóżmy na przykład, że masz dwa przepływy pracy, z których każdy ma wyzwalacz sondowania, który sprawdza konto e-mail co minutę dla określonego tematu, na przykład "Powodzenie" lub "Niepowodzenie". Ta konfiguracja powoduje 120 wywołań na godzinę. Zamiast tego, jeśli tworzysz pojedynczy nadrzędny przepływ pracy, który sonduje co minutę, ale wywołuje podrzędny przepływ pracy, który jest uruchamiany na podstawie tego, czy temat ma wartość "Powodzenie" lub "Niepowodzenie", w tym przypadku zmniejszysz liczbę testów sondowania do połowy lub 60.
Konfigurowanie przetwarzania wsadowego. (Tylko przepływy pracy użycia)
Jeśli usługa docelowa obsługuje operacje wsadowe, można rozwiązać problem ograniczania przepustowości, przetwarzając elementy w grupach lub partiach, a nie pojedynczo. Aby zaimplementować rozwiązanie przetwarzania wsadowego, należy utworzyć przepływ pracy aplikacji logiki "odbiornik partii" i przepływ pracy aplikacji logiki "nadawcy wsadowego". Nadawca wsadowy zbiera komunikaty lub elementy do momentu spełnienia określonych kryteriów, a następnie wysyła te komunikaty lub elementy w jednej grupie. Odbiornik wsadowy akceptuje tę grupę i przetwarza te komunikaty lub elementy. Aby uzyskać więcej informacji, zobacz Batch process messages in groups (Komunikaty przetwarzania w usłudze Batch w grupach).
Użyj wersji elementu webhook dla wyzwalaczy i akcji, a nie wersji sondowania.
Dlaczego? Wyzwalacz sondowania nadal sprawdza usługę docelową lub system w określonych odstępach czasu. Bardzo częste interwały, takie jak co sekundę, mogą powodować problemy z ograniczaniem przepustowości. Jednak wyzwalacz lub akcja elementu webhook, taka jak element webhook HTTP, tworzy tylko jedno wywołanie usługi docelowej lub systemu, które odbywa się w czasie subskrypcji i żąda, aby miejsce docelowe powiadamiało wyzwalacz lub akcję tylko wtedy, gdy wystąpi zdarzenie. W ten sposób wyzwalacz lub akcja nie musi stale sprawdzać miejsca docelowego.
Dlatego jeśli usługa docelowa lub system obsługuje elementy webhook lub udostępnia łącznik, który ma wersję elementu webhook, ta opcja jest lepsza niż użycie wersji sondowania. Aby zidentyfikować wyzwalacze i akcje elementu webhook, upewnij się, że mają
ApiConnectionWebhooktyp lub że nie wymagają określenia cyklu. Aby uzyskać więcej informacji, zobacz APIConnectionWebhook trigger (Wyzwalacz interfejsu APIConnectionWebhook) i APIConnectionWebhook action (Akcja apiConnectionWebhook).