Azure Storage-szolgáltató (Azure Functions)

Ez a dokumentum az Azure Storage-szolgáltató Durable Functions jellemzőit ismerteti, a teljesítményre és a méretezhetőségre összpontosítva. Az alapértelmezett szolgáltató az Azure Storage-szolgáltató. A példányállapotokat és az üzenetsorokat egy (klasszikus) Azure Storage-fiókban tárolja.

Megjegyzés

A Durable Functions támogatott tárolószolgáltatóiról és összehasonlításuk módjáról a Durable Functions tárolószolgáltatók dokumentációjában talál további információt.

Az Azure Storage-szolgáltatóban az összes függvény végrehajtását az Azure Storage-üzenetsorok vezérlik. A vezénylés és az entitások állapota és előzményei az Azure Tablesben vannak tárolva. Az Azure Blobok és blobbérletek a vezénylési példányok és entitások több alkalmazáspéldány (más néven feldolgozók vagy egyszerűen virtuális gépek) közötti elosztására szolgálnak. Ez a szakasz részletesebben ismerteti a különböző Azure Storage-összetevőket, valamint azt, hogy ezek hogyan befolyásolják a teljesítményt és a méretezhetőséget.

Tárterület-ábrázolás

A feladatközpontok tartósan megőrzik az összes példányállapotot és az összes üzenetet. A vezénylés folyamatának nyomon követéséhez használt adatok gyors áttekintéséért tekintse meg a feladatközpont végrehajtási példáját.

Az Azure Storage-szolgáltató a tárolóban lévő feladatközpontot jelöli a következő összetevők használatával:

• Kettő és három Azure-tábla között. A rendszer két táblát használ a előzmények és a példányállapotok ábrázolására. Ha a Táblapartíció-kezelő engedélyezve van, akkor a rendszer egy harmadik táblát vezet be a partícióadatok tárolására.
• Egy Azure Queue tárolja a tevékenységüzeneteket.
• Egy vagy több Azure Queues tárolja a példányüzeneteket. Az úgynevezett vezérlősorok mindegyike egy partíciót jelöl, amely az összes példányüzenet egy részhalmazához van hozzárendelve a példányazonosító kivonata alapján.
• Néhány további blobtároló, amelyeket a blobok és/vagy nagy méretű üzenetek bérletéhez használnak.

Egy nevű xyzPartitionCount = 4 feladatközpont például a következő üzenetsorokat és táblákat tartalmazza:

Ezután részletesebben ismertetjük ezeket az összetevőket és azok szerepét.

Előzménytábla

Az Előzmények tábla egy Azure Storage-tábla, amely a feladatközpontban található összes vezénylési példány előzményeseményeit tartalmazza. A tábla neve a TaskHubNameHistory formában található. A példányok futtatásakor a rendszer új sorokat ad hozzá ehhez a táblához. A tábla partíciókulcsa a vezénylés példányazonosítójából származik. A példányazonosítók alapértelmezés szerint véletlenszerűek, így biztosítják a belső partíciók optimális elosztását az Azure Storage-ban. A táblázat sorkulcsa az előzményesemények rendezéséhez használt sorszám.

Ha egy vezénylési példányt futtatni kell, a rendszer az Előzmények tábla megfelelő sorait tölti be a memóriába egy tartomány-lekérdezéssel egyetlen táblapartíción belül. Ezeket az előzményeseményeket ezután visszajátssza a vezénylőfüggvény kódjába, hogy visszavezessen a korábban ellenőrzőponttal megadott állapotba. A végrehajtási előzményeknek az ilyen módon történő újraépítésére az Event Sourcing minta hatással van.

Tipp

Az Előzmények táblában tárolt vezénylési adatok a tevékenység és az alvezénylő függvények kimeneti hasznos adatait tartalmazzák. A külső eseményekből származó hasznos adatokat az Előzmények táblában is tárolja a rendszer. Mivel a teljes előzmény minden alkalommal betöltődik a memóriába, amikor egy vezénylőnek végre kell hajtania, egy elég nagy előzmény jelentős memóriaterhelést okozhat egy adott virtuális gépen. A vezénylési előzmények hossza és mérete csökkenthető a nagy vezénylések több részvezénylésre való felosztásával, vagy az általa hívott tevékenység és alvezénylői függvények által visszaadott kimenetek méretének csökkentésével. Azt is megteheti, hogy csökkenti a memóriahasználatot, ha csökkenti a virtuális gépekre vonatkozó egyidejűségi szabályozásokat , így korlátozható, hogy egyszerre hány vezénylés legyen betöltve a memóriába.

Instances tábla

Az Instances tábla a feladatközpontban található összes vezénylési és entitáspéldány állapotát tartalmazza. A példányok létrehozásakor a rendszer új sorokat ad hozzá ehhez a táblához. A tábla partíciókulcsa a vezénylési példány azonosítója vagy entitáskulcsa, a sorkulcs pedig egy üres sztring. Vezénylésenként vagy entitáspéldányonként egy sor van.

Ez a tábla a kódból származó példány lekérdezési kéréseinek , valamint az állapot lekérdezési HTTP API-hívások teljesítésére szolgál. A rendszer végül konzisztens marad a korábban említett Előzmények tábla tartalmával. A parancs- és lekérdezési felelősség elkülönítésének (CQRS) mintája befolyásolja, hogy egy különálló Azure Storage-tábla hogyan tudja hatékonyan kielégíteni a példánylekérdezési műveleteket.

Tipp

Az Instances tábla particionálása lehetővé teszi, hogy több millió vezénylési példányt tároljon anélkül, hogy észrevehető hatással lenne a futásidejű teljesítményre vagy a skálázásra. A példányok száma azonban jelentős hatással lehet a többpéldányos lekérdezési teljesítményre. Az ezekben a táblákban tárolt adatok mennyiségének szabályozásához fontolja meg a régi példányadatok rendszeres törlését.

Partitions table

Megjegyzés

Ez a tábla csak akkor jelenik meg a feladatközpontban, ha Table Partition Manager engedélyezve van. Alkalmazásához konfigurálja useTablePartitionManagement a beállítást az alkalmazás host.json fájljában.

A Partitions tábla az Durable Functions alkalmazás partícióinak állapotát tárolja, és a partíciók az alkalmazás feldolgozói közötti elosztására szolgál. Partíciónként egy sor van.

Üzenetsorok

Az Vezénylő, az entitás és a tevékenységfüggvényeket a függvényalkalmazás feladatközpontjában található belső üzenetsorok aktiválják. Az üzenetsorok ily módon való használata megbízható "legalább egyszer" üzenetkézbesítési garanciákat biztosít. A Durable Functions kétféle üzenetsortípus létezik: a vezérlősor és a munkaelem-üzenetsor.

A munkaelem-üzenetsor

Feladatközpontonként egy munkaelem-üzenetsor van Durable Functions. Ez egy alapszintű üzenetsor, és a Azure Functions többi queueTrigger üzenetsorához hasonlóan viselkedik. Ez az üzenetsor állapot nélküli tevékenységfüggvények aktiválására szolgál egyetlen üzenet egyidejű lekérdezésével. Ezek az üzenetek tevékenységfüggvény-bemeneteket és további metaadatokat tartalmaznak, például azt, hogy melyik függvényt kell végrehajtani. Ha egy Durable Functions-alkalmazás több virtuális gépre skálázható fel, ezek a virtuális gépek mind versenyeznek a tevékenységeknek a munkaelem-üzenetsorból való beszerzéséért.

Üzenetsor(ok) vezérlése

Feladatközpontonként több vezérlősor van Durable Functions. A vezérlősor kifinomultabb, mint az egyszerűbb munkaelem-üzenetsor. A vezérlősorok az állapotalapú vezénylő és az entitásfüggvények aktiválására szolgálnak. Mivel a vezénylő- és entitásfüggvénypéldányok állapotalapú egytonok, fontos, hogy az egyes vezényléseket vagy entitásokat egyszerre csak egy feldolgozó dolgozza fel. A korlátozás eléréséhez minden vezénylési példány vagy entitás egyetlen vezérlősorhoz van rendelve. Ezek a vezérlősorok terheléselosztással vannak elosztva a feldolgozók között, így biztosítva, hogy az egyes üzenetsorokat egyszerre csak egy feldolgozó dolgozza fel. Erről a viselkedésről további részleteket a következő szakaszokban talál.

A vezérlési üzenetsorok számos vezénylési életciklus-üzenettípust tartalmaznak. Ilyenek például a vezénylő vezérlőüzenetei, a tevékenységfüggvény válaszüzenetei és az időzítőüzenetek. Egyetlen szavazásban akár 32 üzenet is le lesz kérve egy vezérlősorból. Ezek az üzenetek hasznos adatokat és metaadatokat tartalmaznak, beleértve azt is, hogy melyik vezénylési példányhoz készült. Ha több lekérdezett üzenet is ugyanahhoz a vezénylési példányhoz van szánva, kötegként lesznek feldolgozva.

A vezérlési üzenetsor üzeneteit a rendszer folyamatosan lekérdezi egy háttérszál használatával. Az egyes üzenetsor-lekérdezések kötegméretét a controlQueueBatchSize host.json beállítás szabályozza, és alapértelmezés szerint 32 (az Azure Queues által támogatott maximális érték). A memóriában pufferelt, előre beszúrt vezérlősor-üzenetek maximális számát a controlQueueBufferThreshold host.json fájlban megadott beállítás szabályozza. Az alapértelmezett érték controlQueueBufferThreshold számos tényezőtől függ, beleértve a szolgáltatási csomag típusát is. További információ ezekről a beállításokról: host.json sémadokumentáció.

Tipp

A érték controlQueueBufferThreshold növelése lehetővé teszi, hogy egyetlen vezénylés vagy entitás gyorsabban dolgozza fel az eseményeket. Ennek az értéknek a növelése azonban magasabb memóriahasználatot is eredményezhet. A nagyobb memóriahasználatot részben az okozza, hogy több üzenetet kell lekérni az üzenetsorból, részben pedig azért, mert több vezénylési előzményt kell beolvasni a memóriába. Ezért a értékének controlQueueBufferThreshold csökkentése hatékonyan csökkentheti a memóriahasználatot.

Üzenetsor-lekérdezés

A tartós feladatbővítmény véletlenszerű exponenciális visszalépési algoritmust implementál, hogy csökkentse az üresjárati várólista-lekérdezések tárolási tranzakciós költségekre gyakorolt hatását. Amikor egy üzenet található, a futtatókörnyezet azonnal egy másik üzenetet keres. Ha nem található üzenet, az egy ideig várakozik, mielőtt újra próbálkozna. Az üzenetsor-üzenet lekérésére tett későbbi sikertelen kísérletek után a várakozási idő tovább nő, amíg el nem éri a maximális várakozási időt, amely alapértelmezés szerint 30 másodperc.

A maximális lekérdezési késleltetés a maxQueuePollingIntervalhost.json fájl tulajdonságán keresztül konfigurálható. Ha ezt a tulajdonságot magasabb értékre állítja, az nagyobb üzenetfeldolgozási késéseket eredményezhet. A nagyobb késések csak inaktivitási időszakok után várhatók. A tulajdonság alacsonyabb értékre állítása magasabb tárolási költségeket eredményezhet a megnövekedett tárolási tranzakciók miatt.

Megjegyzés

Ha a Azure Functions Használat és Prémium csomagban fut, a Azure Functions skálázási vezérlő 10 másodpercenként egyszer kérdezi le az egyes vezérlők és munkaelemek várólistáját. Ez a további lekérdezés a függvényalkalmazás-példányok aktiválásának és a méretezési döntések meghozatalának időpontjának meghatározásához szükséges. Íráskor ez a 10 másodperces időköz állandó, és nem konfigurálható.

Vezénylés indítási késleltetései

A vezénylési példányok úgy indulnak el, hogy üzenetet ExecutionStarted helyeznek el a feladatközpont egyik vezérlősorában. Bizonyos körülmények között több másodperces késések figyelhetők meg a vezénylés ütemezése és a futás tényleges indítása között. Ebben az időtartamban a vezénylési példány állapotban Pending marad. Ennek a késésnek két lehetséges oka lehet:

• Háttérrendszerbeli vezérlősorok: Ha a példány vezérlősora nagy számú üzenetet tartalmaz, időbe telhet, amíg a futtatókörnyezet megkapja és feldolgozta az ExecutionStarted üzenetet. Üzenethátralékok akkor fordulhatnak elő, ha a vezénylések egyszerre sok eseményt dolgoznak fel. A vezérlővárólista eseményei közé tartoznak a vezénylés indítási eseményei, a tevékenységkiegészítések, a tartós időzítők, a megszakítások és a külső események. Ha ez a késés normál körülmények között történik, érdemes lehet nagyobb számú partícióval rendelkező új feladatközpontot létrehozni. Ha több partíciót konfigurál, a futtatókörnyezet több vezérlősort hoz létre a terheléselosztáshoz. Minden partíció 1:1-nek felel meg egy vezérlősorsal, legfeljebb 16 partícióval.

• Lekérdezési késések visszalépése: A vezénylési késések egy másik gyakori oka a korábban leírt visszalépéses lekérdezési viselkedés a vezérlősorok esetében. Ez a késés azonban csak akkor várható, ha egy alkalmazás két vagy több példányra van felskálázva. Ha csak egy alkalmazáspéldány van, vagy ha a vezénylést elindító alkalmazáspéldány is ugyanaz a példány, amely a célvezérlő-üzenetsort kérdezi le, akkor nem lesz várakozási sor lekérdezési késleltetése. A korábbiakban ismertetett host.json beállítások frissítésével csökkenthető a lekérdezési késések visszalépése.

Blobok

A legtöbb esetben a Durable Functions nem használja az Azure Storage-blobokat az adatok megőrzésére. Az üzenetsorok és táblák azonban méretkorlátokkal rendelkeznek, amelyek megakadályozhatják, hogy Durable Functions az összes szükséges adatot tárolósorba vagy üzenetsorba megőrizzék. Ha például egy üzenetsorban megőrzendő adat nagyobb, mint 45 KB szerializálva, Durable Functions tömöríti az adatokat, és blobban tárolja őket. Ha így őrzi meg az adatokat a Blob Storage-ban, a Durable Function az adott blobra mutató hivatkozást tárolja a táblasorban vagy az üzenetsorban. Ha Durable Functions le kell kérnie az adatokat, az automatikusan lekéri azokat a blobból. Ezek a blobok a blobtárolóban <taskhub>-largemessagesvannak tárolva.

A teljesítménnyel kapcsolatos megfontolások

A nagy méretű üzenetek extra tömörítési és blobműveleti lépései költségesek lehetnek a PROCESSZOR- és I/O-késési költségek szempontjából. Emellett a Durable Functions-nak be kell töltenie a memóriába a megőrzött adatokat, és ezt számos különböző függvényvégrehajtás esetén is megteheti egyszerre. Ennek eredményeképpen a nagy adattartalom megőrzése magas memóriahasználatot is okozhat. A memóriaterhelés minimalizálása érdekében fontolja meg a nagy adattartalom manuális megőrzését (például a Blob Storage-ban), és ehelyett adja át az adatokra mutató hivatkozásokat. Így a kód csak szükség esetén tudja betölteni az adatokat, hogy elkerülje a redundáns terhelést a vezénylőfüggvények visszajátszása során. A hasznos adatok helyi lemezekre való tárolása azonban nem ajánlott, mivel a lemezen lévő állapot nem garantált, mivel a függvények különböző virtuális gépeken futtathatók a teljes élettartamuk során.

Tárfiók kiválasztása

A Durable Functions által használt üzenetsorok, táblák és blobok egy konfigurált Azure Storage-fiókban jönnek létre. A használni kívánt fiók a host.json fájlban található durableTask/storageProvider/connectionStringName beállítással (vagy durableTask/azureStorageConnectionStringName Durable Functions 1.x-ben) adható meg.

Durable Functions 2.x

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

Durable Functions 1.x

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

Ha nincs megadva, a rendszer az alapértelmezett AzureWebJobsStorage tárfiókot használja. A teljesítményérzékeny számítási feladatok esetében azonban ajánlott nem alapértelmezett tárfiókot konfigurálni. Durable Functions nagy mértékben használja az Azure Storage-t, és egy dedikált tárfiók használatával elkülöníti Durable Functions tárterület-használatot a Azure Functions gazdagép belső használatától.

Megjegyzés

Az Azure Storage-szolgáltató használatakor standard általános célú Azure Storage-fiókokra van szükség. Az összes többi tárfióktípus nem támogatott. Javasoljuk, hogy az örökölt v1-es verziójú általános célú tárfiókokat használja Durable Functions. Az újabb v2-tárfiókok jelentősen drágábbak lehetnek Durable Functions számítási feladatok esetében. Az Azure Storage-fióktípusokkal kapcsolatos további információkért tekintse meg a Tárfiókok áttekintése dokumentációt.

Az Orchestrator vertikális felskálázása

Bár a tevékenységfüggvények végtelenül horizontálisan felskálázhatók további virtuális gépek rugalmas hozzáadásával, az egyes vezénylőpéldányok és entitások egyetlen partíción való lakottságra vannak korlátozva, és a partíciók maximális számát a beállítás korlátozza a partitionCounthost.jsonsajátban.

Megjegyzés

Általánosságban elmondható, hogy a vezénylő függvények könnyűek, és nem igényelnek nagy számítási teljesítményt. Ezért nem szükséges nagy számú vezérlősor-partíciót létrehozni a vezénylések nagy átviteli sebességének eléréséhez. A nagy munka nagy részét állapot nélküli tevékenységfüggvényekben kell elvégezni, amelyek végtelenül felskálázhatók.

A vezérlősorok száma a host.json fájlban van meghatározva. Az alábbi példa host.json kódrészlete a tulajdonságot (vagy durableTask/partitionCount Durable Functions durableTask/storageProvider/partitionCount 1.x) értékre 3állítja. Vegye figyelembe, hogy annyi vezérlési üzenetsor van, mint a partíciók.

Durable Functions 2.x

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

Durable Functions 1.x

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

A feladatközpontok 1 és 16 partíció között konfigurálhatók. Ha nincs megadva, az alapértelmezett partíciószám 4.

Alacsony forgalmú forgatókönyvek esetén az alkalmazás horizontálisan fel lesz skálázva, így a partíciókat kis számú feldolgozó kezeli. Vegyük például az alábbi diagramot.

Az előző ábrán látható, hogy az 1–6. vezénylők terhelése elosztott a partíciók között. Hasonlóképpen, a partíciók, például a tevékenységek, elosztott terhelést jelentenek a feldolgozók között. A partíciók terheléselosztása a feldolgozók között, függetlenül az első lépésekben szereplő vezénylők számától.

Ha a Azure Functions Consumption vagy Elastic Premium csomagon fut, vagy ha terhelésalapú automatikus skálázás van konfigurálva, a forgalom növekedésével több feldolgozó lesz lefoglalva, és a partíciók végül terheléselosztást fognak elérni az összes feldolgozó között. Ha továbbra is horizontális felskálázást hajtunk végre, végül minden partíciót egyetlen feldolgozó kezel. A tevékenységek viszont továbbra is terheléselosztásra kerülnek az összes feldolgozó között. Ez az alábbi képen látható.

Az egyidejű aktív vezénylések maximális számának felső határa egy adott időpontban megegyezik az alkalmazás számára az értékének maxConcurrentOrchestratorFunctionsidőkorlátjához rendelt feldolgozók számával. Ez a felső határ pontosabb lehet, ha a partíciók teljes mértékben fel vannak skálázva a feldolgozók között. Teljes horizontális felskálázás esetén, és mivel minden feldolgozónak csak egyetlen Functions-gazdagéppéldánya lesz, az aktív egyidejű vezénylőpéldányok maximális száma megegyezik a partíciók számával, mint a értéke.maxConcurrentOrchestratorFunctions

Megjegyzés

Ebben az összefüggésben az aktív azt jelenti, hogy egy vezénylés vagy entitás betöltődik a memóriába, és új eseményeket dolgoz fel. Ha a vezénylés vagy entitás több eseményre vár, például egy tevékenységfüggvény visszatérési értéke, akkor a rendszer eltávolítja a memóriából, és már nem számít aktívnak. A vezénylések és entitások ezután csak akkor töltődnek be újra a memóriába, ha új eseményeket kell feldolgozni. Az egyetlen virtuális gépen futtatható vezénylések és entitások maximális száma nem érhető el, még akkor sem, ha mindegyik "Fut" állapotban van. Az egyetlen korlátozás az egyidejűleg aktív vezénylési vagy entitáspéldányok száma.

Az alábbi kép egy teljes mértékben felskálázott forgatókönyvet mutat be, amelyben több vezénylőt adnak hozzá, de némelyik inaktív, szürke színnel jelenik meg.

A horizontális felskálázás során a vezérlési várólista-bérletek újraelosztásra kerülhetnek a Functions-gazdagéppéldányok között, hogy a partíciók egyenletesen legyenek elosztva. Ezek a bérletek belsőleg Azure Blob Storage-bérletként vannak implementálva, és biztosítják, hogy az egyes vezénylési példányok vagy entitások egyszerre csak egyetlen gazdagéppéldányon fussanak. Ha egy feladatközpont három partícióval (és így három vezérlősorsal) van konfigurálva, a vezénylési példányok és az entitások terheléselosztása mindhárom bérlet-holding gazdagéppéldány között elosztható. További virtuális gépek is hozzáadhatók a tevékenységfüggvény-végrehajtás kapacitásának növeléséhez.

Az alábbi ábra azt szemlélteti, hogy a Azure Functions gazdagép hogyan kommunikál a kibővített környezetben található tárolóentitással.

Ahogy az előző ábrán is látható, az összes virtuális gép versenyez a munkaelem-üzenetsor üzenetsorán lévő üzenetekért. A vezérlősorokból azonban csak három virtuális gép tud üzeneteket beszerezni, és mindegyik virtuális gép egyetlen vezérlősort zárol.

A vezénylési példányok és entitások az összes vezérlősorpéldány között el vannak osztva. Az elosztás a vezénylés példányazonosítójának vagy az entitásnév és a kulcspár kivonatolásával történik. A vezénylési példányazonosítók alapértelmezés szerint véletlenszerű GUID azonosítók, amelyek biztosítják, hogy a példányok egyenlően legyenek elosztva az összes vezérlősor között.

Általánosságban elmondható, hogy a vezénylő függvények könnyűek, és nem igényelnek nagy számítási teljesítményt. Ezért nem szükséges nagy számú vezérlővárólista-partíciót létrehozni, hogy nagy átviteli sebességet kapjon a vezénylésekhez. A nagy munka nagy részét állapot nélküli tevékenységfüggvényekben kell elvégezni, amelyek végtelenül felskálázhatók.

Bővített munkamenetek

A bővített munkamenetek olyan gyorsítótárazási mechanizmusok , amelyek az üzenetek feldolgozása után is megőrzik a vezényléseket és az entitásokat a memóriában. A kiterjesztett munkamenetek engedélyezésének tipikus hatása a mögöttes tartós tárolóra való csökkentett I/O- és általánosan jobb átviteli sebesség.

A kiterjesztett munkamenetek engedélyezéséhez true a host.json fájlban állítsa durableTask/extendedSessionsEnabled be a értéket. A durableTask/extendedSessionIdleTimeoutInSeconds beállítással szabályozható, hogy mennyi ideig tart egy tétlen munkamenet a memóriában:

Functions 2.0

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

Functions 1.0

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

Ennek a beállításnak két lehetséges hátránya van, amelyeket figyelembe kell vennie:

1. A függvényalkalmazások memóriahasználata összességében megnőtt, mivel a tétlen példányok nem kerülnek ki a memóriából ilyen gyorsan.
2. Az átviteli sebesség összességében csökkenhet, ha sok egyidejű, különálló, rövid élettartamú vezénylő vagy entitásfüggvény-végrehajtás van.

Ha például durableTask/extendedSessionIdleTimeoutInSeconds 30 másodpercre van állítva, akkor egy rövid élettartamú vezénylő vagy entitásfüggvény-epizód, amely kevesebb mint 1 másodperc alatt fut le, továbbra is 30 másodpercig foglalja el a memóriát. Emellett beleszámít a durableTask/maxConcurrentOrchestratorFunctions korábban említett kvótába is, ami megakadályozhatja, hogy más vezénylő- vagy entitásfüggvények fussanak.

A kiterjesztett munkamenetek vezénylőire és entitásfüggvényeire gyakorolt konkrét hatásait a következő szakaszok ismertetik.

Megjegyzés

A bővített munkamenetek jelenleg csak .NET-nyelveken támogatottak, például C# vagy F# nyelven. true A más platformokra való beállítás extendedSessionsEnabled futásidejű problémákhoz vezethet, például a tevékenységek és a vezénylés által aktivált függvények csendes sikertelen végrehajtásához.

Orchestrator-függvény visszajátszása

Ahogy korábban említettük, a vezénylőfüggvények az Előzmények tábla tartalmával lesznek lejátszva. Alapértelmezés szerint a vezénylőfüggvény kódja minden alkalommal újra le van játszva, amikor egy üzenetköteg le van törölve egy vezérlősorból. Még akkor is, ha a ki- és besugárzó mintát használja, és az összes feladat befejezésére vár (például Task.WhenAll() .NET-ben, context.df.Task.all() JavaScriptben vagy context.task_all() Pythonban), akkor is lesznek olyan visszajátszások, amelyek a feladatválaszok kötegeinek feldolgozásakor fordulnak elő. Ha a bővített munkamenetek engedélyezve vannak, a vezénylőfüggvénypéldányok hosszabb ideig maradnak a memóriában, és az új üzenetek teljes előzmény-visszajátszás nélkül feldolgozhatók.

A kiterjesztett munkamenetek teljesítménybeli javulását leggyakrabban a következő helyzetekben figyelik meg:

• Ha korlátozott számú vezénylési példány fut egyszerre.
• Ha a vezénylések nagyszámú szekvenciális műveletet (például több száz tevékenységfüggvény-hívást) hajtanak végre, amelyek gyorsan befejeződnek.
• Amikor a vezénylések nagy számú műveletben hajtják végre a ki-ki és a ventilátort, amelyek nagyjából egy időben fejeződnek be.
• Ha a vezénylő függvénynek nagy méretű üzeneteket kell feldolgoznia, vagy processzorigényes adatfeldolgozást kell végeznie.

Az összes többi helyzetben általában nincs megfigyelhető teljesítménybeli javulás a vezénylői funkciók esetében.

Megjegyzés

Ezeket a beállításokat csak a vezénylőfüggvények teljes körű fejlesztése és tesztelése után szabad használni. Az alapértelmezett agresszív visszajátszási viselkedés hasznos lehet a vezénylőfüggvények kódkorlátozásainak a fejlesztési időben való észleléséhez, ezért alapértelmezés szerint le van tiltva.

Teljesítménycélok

Az alábbi táblázat a Teljesítmény és skálázás című cikk Teljesítménycélok szakaszában ismertetett forgatókönyvek várható maximális átviteli sebességét mutatja be.

A "példány" a vezénylőfüggvények egyetlen példányára utal, amely egyetlen kis méretű (A1) virtuális gépen fut Azure App Service. A rendszer minden esetben azt feltételezi, hogy a kiterjesztett munkamenetek engedélyezve vannak. A tényleges eredmények a függvénykód által végzett PROCESSZOR- vagy I/O-munka függvényében változhatnak.

Eset	Maximális átviteli sebesség
Szekvenciális tevékenységek végrehajtása	Példányonként 5 tevékenység másodpercenként
Párhuzamos tevékenységek végrehajtása (ki-ki)	Példányonként 100 tevékenység másodpercenként
Párhuzamos válaszfeldolgozás (ventilátor)	Példányonként 150 válasz másodpercenként
Külső eseményfeldolgozás	Példányonként 50 esemény másodpercenként
Entitásművelet feldolgozása	Másodpercenként 64 művelet

Ha nem látja a várt átviteli sebességet, és a processzor- és memóriahasználat kifogástalannak tűnik, ellenőrizze, hogy az ok a tárfiók állapotával kapcsolatos-e. A Durable Functions bővítmény jelentős terhelést okozhat egy Azure Storage-fiók számára, és a kellően nagy terhelés a tárfiók szabályozását eredményezheti.

Tipp

Bizonyos esetekben jelentősen növelheti a külső események, a tevékenységventilátor és az entitásműveletek átviteli sebességét a host.json fájlban található controlQueueBufferThreshold beállítás értékének növelésével. Ha ezt az értéket az alapértelmezett értéknél nagyobbra növeli, a Durable Task Framework tárolószolgáltatója több memóriát használ az események agresszívebb előbetöltéséhez, csökkentve az Azure Storage-vezérlősorok üzeneteinek törléséhez kapcsolódó késéseket. További információ: host.json referenciadokumentáció.

Nagy átviteli sebességű feldolgozás

Az Azure Storage háttérrendszer architektúrája bizonyos korlátozásokat alkalmaz a Durable Functions maximális elméleti teljesítményére és méretezhetőségére. Ha a tesztelés azt mutatja, hogy az Azure Storage-Durable Functions nem felelnek meg az átviteli sebességre vonatkozó követelményeknek, érdemes inkább a Netherite tárolószolgáltatót használni a Durable Functions.

A különböző alapforgatókönyvek elérhető átviteli sebességének összehasonlításához tekintse meg a Netherite storage provider dokumentációjának Alapforgatókönyvek című szakaszát.

A Netherite storage háttérrendszerét a Microsoft Research tervezte és fejlesztette ki. A Azure Event Hubs és a GYORSABB adatbázis-technológiát használja az Azure Page Blobson. A Netherite kialakítása jelentősen nagyobb átviteli sebességet tesz lehetővé a vezénylések és entitások más szolgáltatókhoz képest. Egyes teljesítményteszt-forgatókönyvekben az átviteli sebesség az alapértelmezett Azure Storage-szolgáltatóhoz képest több mint nagyságrenddel nőtt.

A Durable Functions támogatott tárolószolgáltatóiról és összehasonlításuk módjáról a Durable Functions tárolószolgáltatók dokumentációjában talál további információt.

Következő lépések

Tudnivalók a vészhelyreállításról és a geoterjesztésről