Dostawca usługi Azure Storage (Azure Functions)

W tym dokumencie opisano cechy Durable Functions dostawcy usługi Azure Storage, koncentrując się na aspektach wydajności i skalowalności. Dostawca usługi Azure Storage jest domyślnym dostawcą. Przechowuje stany i kolejki wystąpień na koncie usługi Azure Storage (wersja klasyczna).

Uwaga

Aby uzyskać więcej informacji na temat obsługiwanych dostawców magazynu dla Durable Functions i sposobu ich porównywania, zobacz dokumentację dostawców magazynu Durable Functions.

W dostawcy usługi Azure Storage wszystkie wykonania funkcji są sterowane przez kolejki usługi Azure Storage. Orkiestracja i stan jednostki i historia są przechowywane w tabelach platformy Azure. Obiekty blob platformy Azure i dzierżawy obiektów blob są używane do dystrybucji wystąpień i jednostek orkiestracji w wielu wystąpieniach aplikacji (nazywanych również procesami roboczymi lub po prostu maszynami wirtualnymi). Ta sekcja zawiera bardziej szczegółowe informacje na temat różnych artefaktów usługi Azure Storage oraz ich wpływu na wydajność i skalowalność.

Reprezentacja magazynu

Centrum zadań trwale utrzymuje wszystkie stany wystąpienia i wszystkie komunikaty. Aby zapoznać się z krótkim omówieniem sposobu ich użycia do śledzenia postępu orkiestracji, zobacz przykład wykonywania centrum zadań.

Dostawca usługi Azure Storage reprezentuje centrum zadań w magazynie przy użyciu następujących składników:

• Między dwiema i trzema tabelami platformy Azure. Dwie tabele są używane do reprezentowania historii i stanów wystąpień. Jeśli menedżer partycji tabel jest włączony, trzecia tabela zostanie wprowadzona do przechowywania informacji o partycji.
• Jedna kolejka platformy Azure przechowuje komunikaty o aktywności.
• Co najmniej jedna kolejka platformy Azure przechowuje komunikaty wystąpienia. Każda z tych tak zwanych kolejek kontrolnych reprezentuje partycję , która jest przypisana podzestaw wszystkich komunikatów wystąpień na podstawie skrótu identyfikatora wystąpienia.
• Kilka dodatkowych kontenerów obiektów blob używanych do dzierżawy obiektów blob i/lub dużych komunikatów.

Na przykład centrum zadań o nazwie xyz with PartitionCount = 4 zawiera następujące kolejki i tabele:

Następnie opiszemy te składniki i rolę, jaką pełnią bardziej szczegółowo.

Tabela historii

Tabela Historia to tabela usługi Azure Storage zawierająca zdarzenia historii dla wszystkich wystąpień aranżacji w centrum zadań. Nazwa tej tabeli ma postać Historia TaskHubName. W miarę uruchamiania wystąpień nowe wiersze są dodawane do tej tabeli. Klucz partycji tej tabeli pochodzi z identyfikatora wystąpienia orkiestracji. Identyfikatory wystąpień są domyślnie losowe, zapewniając optymalną dystrybucję partycji wewnętrznych w usłudze Azure Storage. Klucz wiersza dla tej tabeli jest numerem sekwencji używanym do porządkowania zdarzeń historii.

Gdy wystąpienie orkiestracji musi zostać uruchomione, odpowiednie wiersze tabeli Historia są ładowane do pamięci przy użyciu zapytania zakresu w ramach jednej partycji tabeli. Te zdarzenia historii są następnie odtwarzane w kodzie funkcji orkiestratora, aby wrócić do poprzedniego stanu punktu kontrolnego. Użycie historii wykonywania do odbudowy stanu w ten sposób ma wpływ na wzorzec określania źródła zdarzeń.

Porada

Dane orkiestracji przechowywane w tabeli Historia zawierają ładunki wyjściowe z funkcji działania i podarantora. Ładunki z zdarzeń zewnętrznych są również przechowywane w tabeli Historia. Ponieważ pełna historia jest ładowana do pamięci za każdym razem, gdy orkiestrator musi wykonać, wystarczająco duża historia może spowodować znaczne wykorzystanie pamięci na danej maszynie wirtualnej. Długość i rozmiar historii aranżacji można zmniejszyć przez podzielenie dużych aranżacji na wiele podaranżacji lub zmniejszenie rozmiaru danych wyjściowych zwracanych przez działanie i funkcje podrzędne, które wywołuje. Alternatywnie można zmniejszyć użycie pamięci, obniżając ograniczenia współbieżności na maszynę wirtualną, aby ograniczyć liczbę aranżacji ładowanych do pamięci współbieżnie.

Tabela Wystąpień

Tabela Instances zawiera stany wszystkich wystąpień orkiestracji i jednostek w centrum zadań. Podczas tworzenia wystąpień do tej tabeli są dodawane nowe wiersze. Kluczem partycji tej tabeli jest identyfikator wystąpienia aranżacji lub klucz jednostki, a klucz wiersza jest pustym ciągiem. Istnieje jeden wiersz na aranżację lub wystąpienie jednostki.

Ta tabela służy do spełnienia żądań zapytań dotyczących wystąpienia z kodu , a także zapytań o stan wywołań interfejsu API PROTOKOŁU HTTP . Jest ona ostatecznie zgodna z zawartością wymienionej wcześniej tabeli Historia . Użycie oddzielnej tabeli usługi Azure Storage w celu wydajnego zaspokojenia operacji zapytań wystąpienia w ten sposób ma wpływ na wzorzec Podziału odpowiedzialności poleceń i zapytań (CQRS).

Porada

Partycjonowanie tabeli Instances umożliwia przechowywanie milionów wystąpień orkiestracji bez zauważalnego wpływu na wydajność i skalę środowiska uruchomieniowego. Jednak liczba wystąpień może mieć znaczący wpływ na wydajność zapytań z wieloma wystąpieniami . Aby kontrolować ilość danych przechowywanych w tych tabelach, rozważ okresowe przeczyszczanie starych danych wystąpienia.

Tabela partycji

Uwaga

Ta tabela jest wyświetlana w centrum zadań tylko wtedy, gdy Table Partition Manager jest włączona. Aby go zastosować, skonfiguruj useTablePartitionManagement ustawienie w pliku host.json aplikacji.

Tabela Partitions (Partycje) przechowuje stan partycji dla aplikacji Durable Functions i służy do dystrybucji partycji między procesami roboczymi aplikacji. Istnieje jeden wiersz na partycję.

Kolejki

Funkcje orkiestratora, jednostki i działania są wyzwalane przez wewnętrzne kolejki w centrum zadań aplikacji funkcji. Użycie kolejek w ten sposób zapewnia niezawodne gwarancje dostarczania komunikatów "co najmniej raz". Istnieją dwa typy kolejek w Durable Functions: kolejka sterowania i kolejka elementów roboczych.

Kolejka elementów roboczych

W Durable Functions istnieje jedna kolejka elementów roboczych na centrum zadań. Jest to podstawowa kolejka i zachowuje się podobnie jak każda inna queueTrigger kolejka w Azure Functions. Ta kolejka służy do wyzwalania funkcji działań bezstanowych przez kolejkowanie pojedynczego komunikatu naraz. Każdy z tych komunikatów zawiera dane wejściowe funkcji działania i dodatkowe metadane, takie jak funkcja do wykonania. Gdy aplikacja Durable Functions jest skalowana w poziomie do wielu maszyn wirtualnych, wszystkie te maszyny wirtualne konkurują o uzyskanie zadań z kolejki elementów roboczych.

Kolejki sterowania

W Durable Functions istnieje wiele kolejek kontrolnych na koncentrator zadań. Kolejka sterowania jest bardziej zaawansowana niż prostsza kolejka elementów roboczych. Kolejki sterujące są używane do wyzwalania funkcji orkiestratora stanowego i jednostki. Ponieważ wystąpienia funkcji orkiestratora i jednostki są stanowymi pojedynczymi, ważne jest, aby każda orkiestracja lub jednostka była przetwarzana tylko przez jednego procesu roboczego naraz. Aby osiągnąć to ograniczenie, każde wystąpienie orkiestracji lub jednostka jest przypisywana do pojedynczej kolejki sterowania. Te kolejki sterowania są ze zrównoważonym obciążeniem między procesami roboczymi, aby upewnić się, że każda kolejka jest przetwarzana tylko przez jeden proces roboczy naraz. Więcej informacji na temat tego zachowania można znaleźć w kolejnych sekcjach.

Kolejki sterujące zawierają różne typy komunikatów cyklu życia aranżacji. Przykłady obejmują komunikaty sterujące orkiestratora, komunikaty odpowiedzi funkcji działania i komunikaty czasomierza. Aż 32 komunikatów zostanie odsuniętych od kolejki kontrolnej w jednym ankiecie. Te komunikaty zawierają dane ładunku, a także metadane, w tym wystąpienie orkiestracji, dla którego jest przeznaczony. Jeśli wiele komunikatów w kolejce jest przeznaczonych dla tego samego wystąpienia orkiestracji, zostaną one przetworzone jako partia.

Komunikaty kolejek sterowania są stale sondowane przy użyciu wątku w tle. Rozmiar partii każdej ankiety kolejki jest kontrolowany przez controlQueueBatchSize ustawienie w pliku host.json i ma wartość domyślną 32 (wartość maksymalna obsługiwana przez kolejki platformy Azure). Maksymalna liczba wstępnie pobranych komunikatów kolejki sterowania, które są buforowane w pamięci, jest kontrolowana przez controlQueueBufferThreshold ustawienie w pliku host.json. Wartość domyślna parametru controlQueueBufferThreshold różni się w zależności od różnych czynników, w tym typu planu hostingu. Aby uzyskać więcej informacji na temat tych ustawień, zobacz dokumentację schematu host.json .

Porada

Zwiększenie wartości parametru controlQueueBufferThreshold umożliwia szybsze przetwarzanie zdarzeń przez pojedynczą orkiestrację lub jednostkę. Jednak zwiększenie tej wartości może również spowodować większe użycie pamięci. Większe użycie pamięci jest częściowo spowodowane ściąganiem większej liczby komunikatów z kolejki, a częściowo z powodu pobierania większej liczby historii aranżacji do pamięci. Zmniejszenie wartości controlQueueBufferThreshold parametru może w związku z tym być skutecznym sposobem zmniejszenia użycia pamięci.

Sondowanie kolejek

Rozszerzenie trwałego zadania implementuje algorytm wycofywania wykładniczego losowego, aby zmniejszyć wpływ sondowania w kolejce bezczynności na koszty transakcji magazynu. Po znalezieniu komunikatu środowisko uruchomieniowe natychmiast wyszukuje inny komunikat. Gdy komunikat nie zostanie znaleziony, czeka przez pewien czas przed ponowną próbą. Po kolejnych nieudanych próbach pobrania komunikatu w kolejce czas oczekiwania będzie się wydłużać, dopóki nie osiągnie maksymalnego czasu oczekiwania, co domyślnie wynosi 30 sekund.

Maksymalne opóźnienie sondowania można skonfigurować za pośrednictwem maxQueuePollingInterval właściwości w pliku host.json. Ustawienie tej właściwości na wyższą wartość może spowodować większe opóźnienia przetwarzania komunikatów. Wyższe opóźnienia będą oczekiwane tylko po okresach braku aktywności. Ustawienie tej właściwości na niższą wartość może spowodować wyższe koszty magazynowania z powodu zwiększonych transakcji magazynu.

Uwaga

Podczas uruchamiania w planach Azure Functions Zużycie i Premium kontroler skalowania Azure Functions sonduje każdą kontrolkę i kolejkę elementów roboczych co 10 sekund. To dodatkowe sondowanie jest niezbędne do określenia, kiedy aktywować wystąpienia aplikacji funkcji i podejmować decyzje dotyczące skalowania. W momencie pisania ten 10-sekundowy interwał jest stały i nie można go skonfigurować.

Opóźnienia uruchamiania aranżacji

Wystąpienia orkiestracji są uruchamiane przez umieszczenie ExecutionStarted komunikatu w jednej z kolejek sterowania centrum zadań. W pewnych warunkach można obserwować wielosekundowe opóźnienia między zaplanowanym uruchomieniem orkiestracji i rozpoczęciem działania. W tym przedziale czasu wystąpienie orkiestracji pozostaje w Pending stanie. Istnieją dwie potencjalne przyczyny tego opóźnienia:

• Kolejki kontrolek z obsługą wsteczną: jeśli kolejka sterowania dla tego wystąpienia zawiera dużą liczbę komunikatów, może upłynąć czas, zanim ExecutionStarted komunikat zostanie odebrany i przetworzony przez środowisko uruchomieniowe. Listy prac komunikatów mogą wystąpić, gdy orkiestracje przetwarzają wiele zdarzeń jednocześnie. Zdarzenia, które przechodzą do kolejki sterowania, obejmują zdarzenia rozpoczęcia aranżacji, uzupełnianie działań, trwałe czasomierze, kończenie i zdarzenia zewnętrzne. Jeśli to opóźnienie wystąpi w normalnych okolicznościach, rozważ utworzenie nowego centrum zadań z większą liczbą partycji. Skonfigurowanie większej liczby partycji spowoduje, że środowisko uruchomieniowe utworzy więcej kolejek kontroli na potrzeby dystrybucji obciążenia. Każda partycja odpowiada 1:1 z kolejką sterowania z maksymalnie 16 partycjami.

• Wycofywanie opóźnień sondowania: Kolejną częstą przyczyną opóźnień aranżacji jest wcześniej opisane zachowanie sondowania wycofywania dla kolejek kontrolnych. Jednak to opóźnienie jest oczekiwane tylko wtedy, gdy aplikacja jest skalowana w poziomie do co najmniej dwóch wystąpień. Jeśli istnieje tylko jedno wystąpienie aplikacji lub wystąpienie aplikacji, które uruchamia orkiestrację, jest również tym samym wystąpieniem, które sonduje docelową kolejkę sterowania, nie będzie opóźnienia sondowania kolejki. Opóźnienia sondowania można zmniejszyć, aktualizując ustawienia host.json zgodnie z wcześniejszym opisem.

Obiekty blob

W większości przypadków Durable Functions nie używa obiektów blob usługi Azure Storage do utrwalania danych. Jednak kolejki i tabele mają limity rozmiaru, które mogą uniemożliwić Durable Functions utrwalanie wszystkich wymaganych danych do wiersza magazynu lub komunikatu kolejki. Na przykład gdy element danych, który musi zostać utrwalone w kolejce, jest większy niż 45 KB podczas serializacji, Durable Functions skompresuje dane i zapisze je w obiekcie blob. W przypadku utrwalania danych do magazynu obiektów blob w ten sposób funkcja Durable Przechowuje odwołanie do tego obiektu blob w wierszu tabeli lub w kolejce komunikatu. Gdy Durable Functions musi pobrać dane, automatycznie pobierze je z obiektu blob. Te obiekty blob są przechowywane w kontenerze <taskhub>-largemessagesobiektów blob.

Zagadnienia dotyczące wydajności

Dodatkowe kroki kompresji i operacji obiektów blob dla dużych komunikatów mogą być kosztowne pod względem kosztów opóźnienia procesora CPU i operacji we/wy. Ponadto Durable Functions musi ładować utrwalone dane w pamięci i może to zrobić w przypadku wielu różnych wykonań funkcji w tym samym czasie. W rezultacie utrwalanie dużych ładunków danych może również spowodować wysokie użycie pamięci. Aby zminimalizować obciążenie pamięci, rozważ ręczne utrwalanie dużych ładunków danych (na przykład w magazynie obiektów blob) i przekazywanie odwołań do tych danych. Dzięki temu kod może ładować dane tylko wtedy, gdy jest to konieczne, aby uniknąć nadmiarowych obciążeń podczas odtwarzania funkcji orkiestratora. Jednak przechowywanie ładunków na dyskach lokalnych nie jest zalecane, ponieważ stan na dysku nie jest gwarantowany, ponieważ funkcje mogą być wykonywane na różnych maszynach wirtualnych przez cały okres ich istnienia.

Wybór konta magazynu

Kolejki, tabele i obiekty blob używane przez Durable Functions są tworzone na skonfigurowanym koncie usługi Azure Storage. Konto do użycia można określić przy użyciu durableTask/storageProvider/connectionStringName ustawienia (lub durableTask/azureStorageConnectionStringName ustawienia w Durable Functions 1.x) w pliku host.json.

Durable Functions 2.x

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "connectionStringName": "MyStorageAccountAppSetting"
      }
    }
  }
}

Durable Functions 1.x

{
  "extensions": {
    "durableTask": {
      "azureStorageConnectionStringName": "MyStorageAccountAppSetting"
    }
  }
}

Jeśli nie zostanie określone, zostanie użyte domyślne AzureWebJobsStorage konto magazynu. W przypadku obciążeń wrażliwych na wydajność zaleca się jednak skonfigurowanie konta magazynu innego niż domyślne. Durable Functions intensywnie używa usługi Azure Storage i używa dedykowanego konta magazynu izoluje użycie magazynu Durable Functions z użycia wewnętrznego przez hosta Azure Functions.

Uwaga

Konta usługi Azure Storage ogólnego przeznaczenia w warstwie Standardowa są wymagane w przypadku korzystania z dostawcy usługi Azure Storage. Wszystkie inne typy kont magazynu nie są obsługiwane. Zdecydowanie zalecamy używanie starszych kont magazynu ogólnego przeznaczenia w wersji 1 dla Durable Functions. Nowsze konta magazynu w wersji 2 mogą być znacznie droższe w przypadku obciążeń Durable Functions. Aby uzyskać więcej informacji na temat typów kont usługi Azure Storage, zobacz dokumentację przeglądu konta magazynu .

Skalowanie programu Orchestrator w poziomie

Chociaż funkcje działania można skalować w poziomie w nieskończoność, dodając więcej maszyn wirtualnych elastycznie, poszczególne wystąpienia orkiestratora i jednostki są ograniczone do zamieszkania pojedynczej partycji, a maksymalna liczba partycji jest ograniczona przez partitionCount ustawienie w elemecie host.json.

Uwaga

Ogólnie rzecz biorąc, funkcje orkiestratora mają być lekkie i nie powinny wymagać dużej mocy obliczeniowej. W związku z tym nie jest konieczne utworzenie dużej liczby partycji kolejki sterowania w celu uzyskania doskonałej przepływności dla aranżacji. Większość ciężkiej pracy należy wykonać w funkcjach bezstanowych działań, które można skalować w poziomie nieskończonie.

Liczba kolejek kontrolnych jest definiowana w pliku host.json . Poniższy przykładowy fragment kodu host.json ustawia durableTask/storageProvider/partitionCount właściwość (lub durableTask/partitionCount w Durable Functions 1.x) na 3wartość . Należy pamiętać, że istnieje tyle kolejek kontrolnych, jak w przypadku partycji.

Durable Functions 2.x

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "partitionCount": 3
      }
    }
  }
}

Durable Functions 1.x

{
  "extensions": {
    "durableTask": {
      "partitionCount": 3
    }
  }
}

Centrum zadań można skonfigurować z przedziałem od 1 do 16 partycji. Jeśli nie zostanie określona, domyślna liczba partycji to 4.

Podczas scenariuszy niskiego ruchu aplikacja będzie skalowana w poziomie, więc partycje będą zarządzane przez niewielką liczbę procesów roboczych. Rozważmy na przykład poniższy diagram.

Na poprzednim diagramie widzimy, że orkiestratory od 1 do 6 są równoważeniem obciążenia między partycjami. Podobnie partycje, takie jak działania, są równoważona obciążeniem między procesami roboczymi. Partycje są zrównoważonymi obciążeniami między procesami roboczymi niezależnie od liczby koordynatorów, które zaczynają pracę.

Jeśli korzystasz z planów Azure Functions Zużycie lub Elastyczna wersja Premium lub jeśli skonfigurowano skalowanie automatyczne oparte na obciążeniu, więcej procesów roboczych zostanie przydzielonych w miarę zwiększania ruchu, a partycje ostatecznie równoważą obciążenie wszystkich procesów roboczych. Jeśli będziemy nadal skalować w poziomie, w końcu każda partycja zostanie ostatecznie zarządzana przez pojedynczy proces roboczy. Z drugiej strony działania będą nadal równoważyć obciążenie wszystkich pracowników. Jest to pokazane na poniższej ilustracji.

Górna granica maksymalnej liczby współbieżnych aktywnych aranżacji w danym momencie jest równa liczbie procesów roboczych przydzielonych do aplikacji , gdy wartość jest maxConcurrentOrchestratorFunctionsrówna wartości . Ta górna granica może być bardziej precyzyjna, gdy partycje są w pełni skalowane w poziomie między procesami roboczymi. W przypadku pełnego skalowania w poziomie i ponieważ każdy proces roboczy będzie miał tylko jedno wystąpienie hosta usługi Functions, maksymalna liczba aktywnych współbieżnych wystąpień orkiestratora będzie równa liczbie partycji razy, gdy wartość jest maxConcurrentOrchestratorFunctionsrówna .

Uwaga

W tym kontekście aktywna oznacza, że orkiestracja lub jednostka jest ładowana do pamięci i przetwarza nowe zdarzenia. Jeśli orkiestracja lub jednostka oczekuje na więcej zdarzeń, takich jak wartość zwracana funkcji działania, zostaje zwolniona z pamięci i nie jest już uznawana za aktywną. Orkiestracje i jednostki zostaną następnie ponownie załadowane do pamięci tylko wtedy, gdy do przetworzenia zostaną wprowadzone nowe zdarzenia. Nie ma praktycznej maksymalnej liczby całkowitych aranżacji ani jednostek, które mogą być uruchamiane na jednej maszynie wirtualnej, nawet jeśli wszystkie znajdują się w stanie "Uruchomiono". Jedynym ograniczeniem jest liczba współbieżnych aktywnych wystąpień orkiestracji lub jednostek.

Na poniższej ilustracji przedstawiono w pełni skalowany w poziomie scenariusz, w którym dodano więcej orkiestratorów, ale niektóre są nieaktywne, wyświetlane w kolorze szarym.

Podczas skalowania w poziomie dzierżawy kolejek kontroli mogą być redystrybuowane w wystąpieniach hostów usługi Functions w celu zapewnienia równomiernej dystrybucji partycji. Dzierżawy te są wdrażane wewnętrznie jako dzierżawy usługi Azure Blob Storage i zapewniają, że każde pojedyncze wystąpienie orkiestracji lub jednostka jest uruchamiane tylko w jednym wystąpieniu hosta w danym momencie. Jeśli centrum zadań jest skonfigurowane z trzema partycjami (a zatem trzema kolejkami kontrolnymi), wystąpienia orkiestracji i jednostki mogą być równoważona obciążeniem we wszystkich trzech wystąpieniach hostów gospodarstwa dzierżawy. Dodatkowe maszyny wirtualne można dodać w celu zwiększenia pojemności wykonywania funkcji działania.

Na poniższym diagramie pokazano, jak host Azure Functions współdziała z jednostkami magazynu w środowisku skalowanym w poziomie.

Jak pokazano na poprzednim diagramie, wszystkie maszyny wirtualne rywalizują o komunikaty w kolejce elementów roboczych. Jednak tylko trzy maszyny wirtualne mogą uzyskiwać komunikaty z kolejek sterowania, a każda maszyna wirtualna blokuje pojedynczą kolejkę sterowania.

Wystąpienia i jednostki orkiestracji są dystrybuowane we wszystkich wystąpieniach kolejki sterowania. Dystrybucja odbywa się przez określenie identyfikatora wystąpienia orkiestracji lub nazwy jednostki i pary kluczy. Identyfikatory wystąpień aranżacji domyślnie to losowe identyfikatory GUID, dzięki czemu wystąpienia są równomiernie rozproszone we wszystkich kolejkach kontrolek.

Ogólnie rzecz biorąc, funkcje orkiestratora mają być lekkie i nie powinny wymagać dużej mocy obliczeniowej. W związku z tym nie jest konieczne utworzenie dużej liczby partycji kolejki sterowania w celu uzyskania doskonałej przepływności dla aranżacji. Większość ciężkiej pracy należy wykonać w funkcjach bezstanowych działań, które można skalować w poziomie nieskończonie.

Sesje rozszerzone

Sesje rozszerzone to mechanizm buforowania , który utrzymuje aranżacje i jednostki w pamięci nawet po zakończeniu przetwarzania komunikatów. Typowy efekt włączania sesji rozszerzonych jest ograniczony do bazowego trwałego magazynu i ogólnej lepszej przepływności.

Sesje rozszerzone można włączyć, ustawiając wartość durableTask/extendedSessionsEnabled na true w pliku host.json . Ustawienie durableTask/extendedSessionIdleTimeoutInSeconds może służyć do kontrolowania, jak długo sesja bezczynności będzie przechowywana w pamięci:

Funkcje 2.0

{
  "extensions": {
    "durableTask": {
      "extendedSessionsEnabled": true,
      "extendedSessionIdleTimeoutInSeconds": 30
    }
  }
}

Funkcje 1.0

{
  "durableTask": {
    "extendedSessionsEnabled": true,
    "extendedSessionIdleTimeoutInSeconds": 30
  }
}

Istnieją dwa potencjalne wady tego ustawienia, które należy wziąć pod uwagę:

1. Występuje ogólny wzrost użycia pamięci aplikacji funkcji, ponieważ wystąpienia bezczynności nie są zwalniane z pamięci tak szybko.
2. Może wystąpić ogólny spadek przepływności, jeśli istnieje wiele współbieżnych, odrębnych, krótkotrwałych wykonań funkcji orkiestratora lub funkcji jednostki.

Jeśli na przykład durableTask/extendedSessionIdleTimeoutInSeconds ustawiono wartość 30 sekund, wówczas krótkotrwały odcinek funkcji lub funkcji jednostki wykonywany w czasie krótszym niż 1 sekunda nadal zajmuje pamięć przez 30 sekund. Jest również liczone względem podanego wcześniej limitu przydziału durableTask/maxConcurrentOrchestratorFunctions , co może potencjalnie uniemożliwić uruchomienie innych funkcji orkiestratora lub jednostki.

Konkretne efekty sesji rozszerzonych na funkcje orkiestratora i jednostki opisano w następnych sekcjach.

Uwaga

Sesje rozszerzone są obecnie obsługiwane tylko w językach .NET, takich jak C# lub F#. Ustawienie na extendedSessionsEnabled wartość dla true innych platform może prowadzić do problemów ze środowiskiem uruchomieniowym, takich jak dyskretne niepowodzenie wykonywania działań i funkcji wyzwalanych przez orkiestrację.

Odtwarzanie funkcji orchestrator

Jak wspomniano wcześniej, funkcje orkiestratora są odtwarzane przy użyciu zawartości tabeli Historia . Domyślnie kod funkcji orkiestratora jest odtwarzany za każdym razem, gdy partia komunikatów jest wyrejestrowana z kolejki sterowania. Nawet jeśli używasz wentylatora, wzorca wentylatora i oczekujesz na ukończenie wszystkich zadań (na przykład w Task.WhenAll() środowisku .NET, context.df.Task.all() w języku JavaScript lub context.task_all() w języku Python), będą odtwarzane, które występują w miarę przetwarzania partii odpowiedzi zadań w czasie. Po włączeniu sesji rozszerzonych wystąpienia funkcji orkiestratora są przechowywane w pamięci dłużej, a nowe komunikaty mogą być przetwarzane bez pełnego odtwarzania historii.

Poprawa wydajności sesji rozszerzonych jest najczęściej obserwowana w następujących sytuacjach:

• Jeśli istnieje ograniczona liczba wystąpień orkiestracji uruchomionych współbieżnie.
• Gdy aranżacje mają dużą liczbę akcji sekwencyjnych (na przykład setki wywołań funkcji działania), które są wykonywane szybko.
• W przypadku orkiestracji fan-out i fan-in dużej liczby akcji, które są wykonywane mniej więcej w tym samym czasie.
• Gdy funkcje orkiestratora muszą przetwarzać duże komunikaty lub wykonywać dowolne przetwarzanie danych intensywnie korzystające z procesora CPU.

We wszystkich innych sytuacjach zwykle nie ma zauważalnej poprawy wydajności funkcji orkiestratora.

Uwaga

Te ustawienia powinny być używane tylko po tym, jak funkcja orkiestratora została w pełni opracowana i przetestowana. Domyślne agresywne zachowanie odtwarzania może być przydatne do wykrywania naruszeń ograniczeń kodu funkcji orkiestratora w czasie programowania i dlatego jest domyślnie wyłączone.

Cele dotyczące wydajności

W poniższej tabeli przedstawiono oczekiwane maksymalne liczby przepływności dla scenariuszy opisanych w sekcji Cele wydajności artykułu Wydajność i skalowanie .

"Wystąpienie" odnosi się do pojedynczego wystąpienia funkcji orkiestratora uruchomionej na jednej małej maszynie wirtualnej (A1) w Azure App Service. We wszystkich przypadkach zakłada się, że sesje rozszerzone są włączone. Rzeczywiste wyniki mogą się różnić w zależności od procesora CPU lub operacji we/wy wykonywanych przez kod funkcji.

Scenariusz	Maksymalna przepływność
Sekwencyjne wykonywanie działań	5 działań na sekundę, na wystąpienie
Równoległe wykonywanie działań (wentylator)	100 działań na sekundę, na wystąpienie
Równoległe przetwarzanie odpowiedzi (wentylator)	150 odpowiedzi na sekundę na wystąpienie
Przetwarzanie zdarzeń zewnętrznych	50 zdarzeń na sekundę, na wystąpienie
Przetwarzanie operacji jednostki	64 operacje na sekundę

Jeśli nie widzisz oczekiwanych numerów przepływności, a użycie procesora CPU i pamięci jest w dobrej kondycji, sprawdź, czy przyczyna jest powiązana z kondycją konta magazynu. Rozszerzenie Durable Functions może spowodować znaczne obciążenie konta usługi Azure Storage i wystarczająco duże obciążenia mogą spowodować ograniczenie przepustowości konta magazynu.

Porada

W niektórych przypadkach można znacznie zwiększyć przepływność zdarzeń zewnętrznych, fan-in działań i operacji jednostki, zwiększając wartość controlQueueBufferThreshold ustawienia w pliku host.json. Zwiększenie tej wartości poza domyślną powoduje, że dostawca magazynu Durable Task Framework używa większej ilości pamięci do wstępnego pobierania tych zdarzeń bardziej agresywnie, co zmniejsza opóźnienia związane z kolejkowaniem komunikatów z kolejek kontroli usługi Azure Storage. Aby uzyskać więcej informacji, zobacz dokumentację referencyjną pliku host.json .

Przetwarzanie o wysokiej przepływności

Architektura zaplecza usługi Azure Storage stawia pewne ograniczenia dotyczące maksymalnej wydajności teoretycznej i skalowalności Durable Functions. Jeśli testowanie pokazuje, że Durable Functions w usłudze Azure Storage nie spełnia wymagań dotyczących przepływności, należy rozważyć użycie dostawcy magazynu Netherite dla Durable Functions.

Aby porównać osiągalną przepływność dla różnych podstawowych scenariuszy, zobacz sekcję Podstawowe scenariusze dostawcy magazynu Netherite.

Zaplecze magazynu Netherite zostało zaprojektowane i opracowane przez firmę Microsoft Research. Używa ona Azure Event Hubs i technologii szybszej bazy danych na podstawie obiektów blob stronicowych platformy Azure. Projekt Netherite umożliwia znacznie wyższe przepływność przetwarzania aranżacji i jednostek w porównaniu z innymi dostawcami. W niektórych scenariuszach porównawczych przepływność została pokazana w celu zwiększenia o więcej niż rzędu wielkości w porównaniu z domyślnym dostawcą usługi Azure Storage.

Aby uzyskać więcej informacji na temat obsługiwanych dostawców magazynu dla Durable Functions i sposobu ich porównywania, zobacz dokumentację dostawców magazynu Durable Functions.

Następne kroki

Dowiedz się więcej o odzyskiwaniu po awarii i dystrybucji geograficznej