Dostawca usługi Azure Storage (Azure Functions)

W tym dokumencie opisano cechy dostawcy usługi Durable Functions 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 wystąpień i kolejki na koncie usługi Azure Storage (wersja klasyczna).

Uwaga

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

W dostawcy usługi Azure Storage wszystkie wykonywanie funkcji jest oparte na kolejkach 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ń orkiestracji i jednostek 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 aranżacji, 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, zostanie wprowadzona trzecia tabela 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 sterowania 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ń do tej tabeli są dodawane nowe wiersze. Klucz partycji tej tabeli pochodzi z identyfikatora wystąpienia aranżacji. Identyfikatory wystąpień są domyślnie losowe, zapewniając optymalną dystrybucję partycji wewnętrznych w usłudze Azure Storage. Klucz wiersza dla tej tabeli to numer sekwencji używany 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 pojedynczej partycji tabeli. Te zdarzenia historii są następnie odtwarzane w kodzie funkcji orkiestratora, aby przywrócić go do poprzedniego stanu punktu kontrolnego. Użycie historii wykonywania do ponownego skompilowania stanu w ten sposób ma wpływ na wzorzec określania źródła zdarzeń.

Napiwek

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żów 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 jednocześnie do pamięci.

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 orkiestracji 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 HTTP. Jest ona ostatecznie zgodna z zawartością tabeli Historia , o której wspomniano wcześniej. 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).

Napiwek

Partycjonowanie tabeli Instances umożliwia przechowywanie milionów wystąpień aranżacji bez zauważalnego wpływu na wydajność lub skalę środowiska uruchomieniowego. Jednak liczba wystąpień może mieć znaczący wpływ na wydajność zapytań obejmujących wiele wystąpień. Aby kontrolować ilość danych przechowywanych w tych tabelach, należy rozważyć 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 ją zastosować, skonfiguruj useTablePartitionManagement ustawienie w 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 kolejki wewnętrzne w centrum zadań aplikacji funkcji. Korzystanie z kolejek w ten sposób zapewnia niezawodne gwarancje dostarczania komunikatów "co najmniej raz". Istnieją dwa typy kolejek w rozszerzeniu Durable Functions: kolejka sterowania i kolejka elementów roboczych.

Kolejka elementów roboczych

W usłudze Durable Functions istnieje jedna kolejka elementów roboczych na centrum zadań. Jest to podstawowa kolejka i działa podobnie jak każda inna queueTrigger kolejka w usłudze Azure Functions. Ta kolejka służy do wyzwalania funkcji działań bezstanowych przez kolejkowanie pojedynczego komunikatu jednocześnie. 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 skaluje się w poziomie do wielu maszyn wirtualnych, wszystkie te maszyny wirtualne konkurują w celu uzyskania zadań z kolejki elementów roboczych.

Kolejki sterowania

W usłudze Durable Functions istnieje wiele kolejek sterujących na koncentrator zadań. Kolejka sterowania jest bardziej zaawansowana niż prostsza kolejka elementów roboczych. Kolejki sterujące służą 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 jednego procesu roboczego 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 komunikaty zostaną odsłoniętych z kolejki kontrolnej w jednym ankiecie. Te komunikaty zawierają dane ładunku, a także metadane, w tym wystąpienie aranżacji, dla którego jest przeznaczony. Jeśli wiele komunikatów w kolejce jest przeznaczonych dla tego samego wystąpienia aranżacji, zostaną one przetworzone jako partia.

Komunikaty kolejki sterowania są stale sondowane przy użyciu wątku w tle. Rozmiar partii każdej ankiety kolejki jest kontrolowany przez controlQueueBatchSize ustawienie w host.json i ma wartość domyślną 32 (maksymalna wartość 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 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.

Napiwek

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 zatem być skutecznym sposobem zmniejszenia użycia pamięci.

Sondowanie kolejek

Rozszerzenie trwałego zadania implementuje losowy algorytm wycofywania wykładniczego, aby zmniejszyć wpływ sondowania w kolejce bezczynności na koszty transakcji magazynu. Po znalezieniu komunikatu środowisko uruchomieniowe natychmiast wyszukuje inny komunikat. Jeśli komunikat nie zostanie znaleziony, czeka przez pewien czas, zanim ponowi próbę. Po kolejnych nieudanych próbach pobrania komunikatu w kolejce czas oczekiwania będzie nadal zwiększany do momentu osiągnięcia maksymalnego czasu oczekiwania, który 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 powinny być 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

W przypadku uruchamiania w planach Zużycie usługi Azure Functions i Premium kontroler skalowania usługi Azure Functions będzie sondowywał 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 zapisu ten 10-sekundowy interwał jest stały i nie można go skonfigurować.

Opóźnienia uruchamiania orkiestracji

Wystąpienia orkiestracji są uruchamiane przez umieszczenie komunikatu ExecutionStarted w jednej z kolejek kontrolnych centrum zadań. W pewnych warunkach można zaobserwować opóźnienia wielosekundowe między zaplanowanym uruchomieniem aranżacji a 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ąć trochę czasu, zanim ExecutionStarted komunikat zostanie odebrany i przetworzony przez środowisko uruchomieniowe. Listy prac komunikatów mogą wystąpić, gdy aranżacje przetwarzają wiele zdarzeń jednocześnie. Zdarzenia, które przechodzą do kolejki sterowania, obejmują zdarzenia rozpoczęcia aranżacji, zakończenia działań, trwałe czasomierze, zakoń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.

• Opóźnienia wycofywania sondowania: kolejną częstą przyczyną opóźnień orkiestracji 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 uruchamiające aranżację jest również tym samym wystąpieniem, które sonduje docelową kolejkę sterowania, wówczas nie będzie opóźnienie sondowania kolejki. Opóźnienie wycofywania sondowania można zmniejszyć, aktualizując ustawienia host.json zgodnie z wcześniejszym opisem.

Obiekty blob

W większości przypadków rozszerzenie 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ć trwałym utrwalaniu wszystkich wymaganych danych w wierszu magazynu lub komunikacie w kolejce. Na przykład gdy część danych, która musi być utrwalone w kolejce, jest większa niż 45 KB w przypadku serializacji, rozszerzenie Durable Functions skompresuje dane i zamiast tego zapisze je w obiekcie blob. W przypadku utrwalania danych w magazynie obiektów blob funkcja Durable przechowuje odwołanie do tego obiektu blob w wierszu tabeli lub w komunikacie kolejki. Gdy rozszerzenie 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 rozszerzenie 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 związku z tym 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 powtarzania 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łe ich okresy istnienia.

Wybór konta magazynu

Kolejki, tabele i obiekty blob używane przez rozszerzenie 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 rozszerzeniu 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ślony, 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. Rozszerzenie Durable Functions intensywnie korzysta z usługi Azure Storage i korzysta z dedykowanego konta magazynu izoluje użycie magazynu Durable Functions od użycia wewnętrznego przez hosta usługi 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 rozszerzenia 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 orkiestratora w poziomie

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

Uwaga

Ogólnie rzecz biorąc, funkcje orkiestratora mają być lekkie i nie powinny wymagać dużych ilości 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 na potrzeby aranżacji. Większość ciężkiej pracy należy wykonać w funkcjach działań bezstanowych, które można skalować w poziomie bez ograniczeń.

Liczba kolejek kontrolnych jest zdefiniowana w pliku host.json . Poniższy przykład host.json fragment kodu ustawia durableTask/storageProvider/partitionCount właściwość (lub durableTask/partitionCount w rozszerzeniu Durable Functions 1.x) na 3wartość . Należy pamiętać, że istnieje tyle kolejek kontrolnych, ile są partycje.

Durable Functions 2.x

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

Durable Functions 1.x

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

Centrum zadań można skonfigurować z zakresu 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ą ze zrównoważonym obciążeniem między partycjami. Podobnie partycje, takie jak działania, są ze zrównoważonym obciążeniem między procesami roboczymi. Partycje są ze zrównoważonym obciążeniem między procesami roboczymi niezależnie od liczby koordynatorów, które zaczynają pracę.

Jeśli korzystasz z planów użycia usługi Azure Functions lub elastycznej warstwy Premium lub jeśli skonfigurowano automatyczne skalowanie 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, ostatecznie każda partycja zostanie ostatecznie zarządzana przez jednego procesu roboczego. Z drugiej strony działania będą nadal wyważać obciążenie dla wszystkich procesów roboczych. 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 w przypadku wartości .maxConcurrentOrchestratorFunctions Ta górna granica może być bardziej precyzyjna, gdy partycje są w pełni skalowane w poziomie między procesami roboczymi. W przypadku w pełni skalowanego w poziomie i ponieważ każdy proces roboczy będzie miał tylko jedno wystąpienie hosta usługi Functions, maksymalna liczba aktywnych równoczesnych wystąpień orkiestratora będzie równa liczbie partycji, ile razy wartość wynosi maxConcurrentOrchestratorFunctions.

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ż uważana za aktywną. Orkiestracje i jednostki zostaną następnie ponownie załadowane do pamięci tylko wtedy, gdy istnieją nowe zdarzenia do przetworzenia. Nie ma praktycznej maksymalnej liczby całkowitych aranżacji lub jednostek, które mogą być uruchamiane na jednej maszynie wirtualnej, nawet jeśli są w stanie "Uruchomiono". Jedynym ograniczeniem jest liczba współbieżnie aktywnych wystąpień orkiestracji lub jednostek.

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

Podczas skalowania w poziomie dzierżawy kolejek kontroli mogą być redystrybuowane w wystąpieniach hostów usługi Functions, aby zapewnić równomierną dystrybucję partycji. Te dzierżawy są implementowane wewnętrznie jako dzierżawy usługi Azure Blob Storage i zapewniają, że każde pojedyncze wystąpienie orkiestracji lub jednostka działa tylko w jednym wystąpieniu hosta w danym momencie. Jeśli centrum zadań jest skonfigurowane z trzema partycjami (i w związku z tym trzema kolejkami sterowania), wystąpienia orkiestracji i jednostki mogą być wyważone w ramach wszystkich trzech wystąpień hosta gospodarstwa dzierżawy. Dodatkowe maszyny wirtualne można dodać, aby zwiększyć pojemność wykonywania funkcji działania.

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

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

Wystąpienia i jednostki orkiestracji są dystrybuowane we wszystkich wystąpieniach kolejki sterowania. Dystrybucja jest wykonywana przez określenie wartości skrótu identyfikatora wystąpienia orkiestracji lub nazwy jednostki i pary kluczy. Identyfikatory wystąpień orkiestracji 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żych ilości 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 aranżacji. Większość ciężkiej pracy należy wykonać w funkcjach działań bezstanowych, które można skalować w poziomie bez ograniczeń.

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 polega na zmniejszeniu liczby operacji we/wy względem bazowego trwałego magazynu i ogólnej ulepszonej przepływności.

Sesje rozszerzone można włączyć, ustawiając wartość durableTask/extendedSessionsEnabled true na 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:

Functions 2.0

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

Functions 1.0

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

Istnieją dwa potencjalne wady tego ustawienia, o których należy pamiętać:

1. Istnieje ogólny wzrost użycia pamięci aplikacji funkcji, ponieważ wystąpienia bezczynności nie są zwalniane z pamięci tak szybko.
2. Istnieje 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 orkiestratora lub funkcji jednostki wykonywany w czasie krótszym niż 1 sekunda nadal zajmuje pamięć przez 30 sekund. Jest również liczone względem wymienionego durableTask/maxConcurrentOrchestratorFunctions wcześniej limitu przydziału, co potencjalnie uniemożliwia uruchamianie innych funkcji orkiestratora lub jednostki.

Konkretne skutki 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# (tylko model w procesie) 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ę.

Replay 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 odseparowana od kolejki sterującej. Nawet jeśli używasz wzorca fan-out, fan-in i oczekujesz na ukończenie wszystkich zadań (na przykład przy użyciu platformy Task.WhenAll() .NET, context.df.Task.all() w języku JavaScript lub context.task_all() Python), w miarę upływu czasu będą przetwarzane powtórki, które występują w miarę przetwarzania partii odpowiedzi zadań. 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 zakończą się 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łączony.

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 Performance and Scale (Cele wydajności i skalowania).

"Wystąpienie" odnosi się do pojedynczego wystąpienia funkcji orkiestratora uruchomionej na jednej małej maszynie wirtualnej (A1) w usłudze aplikacja systemu Azure 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ń (fan-out)	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 liczb 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.

Napiwek

W niektórych przypadkach można znacznie zwiększyć przepływność zdarzeń zewnętrznych, fan-in działań i operacji jednostek, zwiększając wartość controlQueueBufferThreshold ustawienia w 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ą host.json .

Plan elastycznego zużycia

Plan Flex Consumption to plan hostingu usługi Azure Functions, który zapewnia wiele korzyści z planu Zużycie, w tym model rozliczeń bezserwerowych, a także dodawanie przydatnych funkcji, takich jak sieć prywatna, wybór rozmiaru pamięci wystąpienia i pełna obsługa uwierzytelniania tożsamości zarządzanej.

Usługa Azure Storage jest obecnie jedynym obsługiwanym dostawcą magazynu dla rozszerzenia Durable Functions, który jest hostowany w planie Flex Consumption.

Podczas hostowania rozszerzenia Durable Functions w planie Flex Consumption należy postępować zgodnie z tymi zaleceniami dotyczącymi wydajności:

• Ustaw zawsze gotową liczbę wystąpień dla durable grupy na 1wartość . Dzięki temu zawsze istnieje jedno wystąpienie gotowe do obsługi żądań związanych z usługą Durable Functions, co zmniejsza zimny start aplikacji.
• Zmniejsz interwał sondowania kolejki do 10 sekund lub mniej. Ponieważ ten typ planu jest bardziej wrażliwy na opóźnienia sondowania w kolejce, obniżenie interwału sondowania pomoże zwiększyć częstotliwość operacji sondowania, dzięki czemu żądania są obsługiwane szybciej. Jednak częstsze operacje sondowania prowadzą do wyższego kosztu konta usługi Azure Storage.

Przetwarzanie o wysokiej przepływności

Architektura zaplecza usługi Azure Storage stawia pewne ograniczenia dotyczące maksymalnej wydajności teoretycznej i skalowalności rozszerzenia Durable Functions. Jeśli testy pokazują, że rozszerzenie 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 rozszerzenia Durable Functions.

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

Zaplecze magazynu Netherite zostało zaprojektowane i opracowane przez firmę Microsoft Research. Korzysta z usługi Azure Event Hubs i technologii szybszej bazy danych w oparciu o stronicowe obiekty blob 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, aby zwiększyć się o więcej niż kolejność 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 rozszerzenia Durable Functions i ich porównywania, zobacz dokumentację dostawców magazynu Durable Functions.

Następne kroki

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