Teljesítmény és méretezés a Durable Functionsben (Azure Functions)

A teljesítmény és a méretezhetőség optimalizálása érdekében fontos tisztában lenni a Durable Functions egyedi méretezési jellemzőivel. Ebben a cikkben bemutatjuk, hogyan méretezhetők a feldolgozók a terhelés alapján, és hogyan lehet finomhangolni a különböző paramétereket.

Feldolgozó skálázása

A tevékenységközpont koncepciójának alapvető előnye, hogy a tevékenységközpont munkaelemeit feldolgozó feldolgozó feldolgozók száma folyamatosan módosítható. Az alkalmazások különösen akkor adhatnak hozzá több feldolgozót (vertikális felskálázást), ha a munkát gyorsabban kell feldolgozni, és eltávolíthatják a dolgozókat (vertikális felskálázás), ha nincs elegendő munka a dolgozók elfoglaltsága érdekében. Akár nullára is skálázható, ha a tevékenységközpont teljesen tétlen. Nullára skálázva egyáltalán nincsenek feldolgozók; csak a méretezési vezérlőnek és a tárolónak kell aktívnak maradnia.

Az alábbi ábra ezt a fogalmat szemlélteti:

Automatikus skálázás

A Használat és rugalmas prémium csomagokban futó Összes Azure-függvényhez hasonlóan a Durable Functions is támogatja az automatikus skálázást az Azure Functions skálázási vezérlőjével. A Méretezési vezérlő figyeli, hogy mennyi ideig kell várnia az üzeneteknek és a feladatoknak a feldolgozásuk előtt. Ezek alapján a késések alapján eldöntheti, hogy hozzáadja vagy eltávolítja-e a feldolgozókat.

Feljegyzés

A Durable Functions 2.0-tól kezdve a függvényalkalmazások úgy konfigurálhatók, hogy az Elastic Premium csomag VNET által védett szolgáltatásvégpontjaiban fussanak. Ebben a konfigurációban a Durable Functions a Méretezési vezérlő helyett skálázási kérelmeket kezdeményez. További információ: Futtatókörnyezeti skálázás monitorozása.

Prémium csomag esetén az automatikus skálázás segíthet abban, hogy a dolgozók száma (és ezáltal az üzemeltetési költség) nagyjából arányos legyen az alkalmazás által tapasztalt terheléssel.

Processzorhasználat

Az Orchestrator-függvények egyetlen szálon futnak, így biztosítható, hogy a végrehajtás számos visszajátszásban determinisztikus legyen. Emiatt az egyszálas végrehajtás miatt fontos, hogy a vezénylő függvényszálak ne végezzenek cpu-igényes feladatokat, ne végezzenek I/O-t vagy tiltsa le bármilyen okból. Minden olyan munkát, amely I/O-t, blokkolást vagy több szálat igényelhet, át kell helyezni a tevékenységfüggvényekbe.

A tevékenységfüggvények viselkedése megegyezik a normál üzenetsor által aktivált függvényekkel. Biztonságosan végezhetnek I/O-műveleteket, processzorigényes műveleteket hajthatnak végre, és több szálat is használhatnak. Mivel a tevékenységindítók állapot nélküliek, szabadon skálázhatók korlátlan számú virtuális gépre.

Az entitásfüggvények egyetlen szálon is végrehajthatók, és a műveletek feldolgozása egyenként történik. Az entitásfüggvények azonban nem korlátozzák a végrehajtható kód típusát.

Függvény időtúllépései

A tevékenység-, vezénylő- és entitásfüggvényekre ugyanazok a függvényidőkorlátok vonatkoznak , mint az összes Azure Functionsre. A Durable Functions általános szabályként ugyanúgy kezeli a függvény időtúllépéseit, mint az alkalmazáskód által elvetett kezeletlen kivételeket.

Ha például egy tevékenység túllépi az időkorlátot, a függvény végrehajtása sikertelenként lesz rögzítve, és a vezénylő értesítést kap, és az időtúllépést ugyanúgy kezeli, mint bármely más kivételt: az újrapróbálkozások akkor történnek, ha a hívás meg van adva, vagy egy kivételkezelő végrehajtható.

Entitásművelet kötegelése

A teljesítmény javítása és a költségek csökkentése érdekében egyetlen munkaelem teljes entitásműveletet hajthat végre. A használati tervekben a kötegek számlázása ezután egyetlen függvényvégrehajtásként történik.

Alapértelmezés szerint a köteg maximális mérete 50 a használati csomagok esetében, és 5000 az összes többi csomag esetében. A köteg maximális mérete a host.json fájlban is konfigurálható. Ha a köteg maximális mérete 1, a kötegelés gyakorlatilag le van tiltva.

Feljegyzés

Ha az egyes entitásműveletek végrehajtása hosszú időt vesz igénybe, hasznos lehet a maximális kötegméret korlátozása a függvény időtúllépési kockázatának csökkentése érdekében, különösen a használati tervek esetében.

Példány gyorsítótárazása

A vezénylési munkaelem feldolgozásához a feldolgozónak általában mindkét

1. Kérje le a vezénylési előzményeket.
2. A vezénylési kód visszajátszása az előzmények használatával.

Ha ugyanaz a feldolgozó több munkaelemet dolgoz fel ugyanahhoz a vezényléshez, a tárolószolgáltató optimalizálhatja ezt a folyamatot a feldolgozó memóriájában lévő előzmények gyorsítótárazásával, ami kiküszöböli az első lépést. Emellett gyorsítótárazhatja a végrehajtás közbeni vezénylőt, amely kiküszöböli a második lépést, az előzmények visszajátszását is.

A gyorsítótárazás jellemző hatása a mögöttes tárolási szolgáltatással szemben csökkentett I/O, és általánosan javult az átviteli sebesség és a késés. A gyorsítótárazás viszont növeli a feldolgozó memóriahasználatát.

A példányok gyorsítótárazását jelenleg az Azure Storage-szolgáltató és a Netherite storage-szolgáltató támogatja. Az alábbi táblázat összehasonlítást nyújt.

	Azure Storage-szolgáltató	Netherite storage provider	MSSQL-tárolószolgáltató
Példány gyorsítótárazása	Támogatott (csak a.NET folyamaton belüli feldolgozója)	Támogatott	Nem támogatott
Alapértelmezett beállítás	Disabled (Letiltva)	Engedélyezve	n.a.
Mechanizmus	Bővített munkamenetek	Példánygyorsítótár	n.a.
Documentation	Kiterjesztett munkamenetek megtekintése	Lásd: Példánygyorsítótár	n.a.

Tipp.

A gyorsítótárazás csökkentheti az előzmények visszajátszásának gyakoriságát, de nem tudja teljesen kiküszöbölni a visszajátszást. Vezénylők fejlesztésekor javasoljuk, hogy tesztelje őket olyan konfiguráción, amely letiltja a gyorsítótárazást. Ez a kényszerített visszajátszási viselkedés hasznos lehet a vezénylő függvénykód korlátozásainak a fejlesztési időben történő megsértésének észleléséhez.

Gyorsítótárazási mechanizmusok összehasonlítása

A szolgáltatók különböző mechanizmusokkal implementálják a gyorsítótárazást, és különböző paramétereket kínálnak a gyorsítótárazási viselkedés konfigurálásához.

• Az Azure Storage-szolgáltató által használt kiterjesztett munkamenetek a végrehajtás közbeni vezénylőket a memóriában tartják, amíg egy ideig tétlenek nem lesznek. A mechanizmus vezérléséhez használt paraméterek a következők extendedSessionsEnabled : és extendedSessionIdleTimeoutInSeconds. További részletekért tekintse meg az Azure Storage-szolgáltató dokumentációjának bővített munkameneteit ismertető szakaszt.

Feljegyzés

A kiterjesztett munkamenetek csak a folyamaton belüli .NET-feldolgozóban támogatottak.

• A Netherite storage-szolgáltató által használt példánygyorsítótár megőrzi az összes példány állapotát, beleértve azok előzményeit is a feldolgozó memóriájában, miközben nyomon követi a felhasznált teljes memóriát. Ha a gyorsítótár mérete meghaladja a konfigurált InstanceCacheSizeMBkorlátot, a rendszer kizárja a legutóbb használt példányadatokat. Ha CacheOrchestrationCursors igaz értékre van állítva, a gyorsítótár a végrehajtás közbeni vezénylőket és a példány állapotát is tárolja. További részletekért tekintse meg a Netherite storage-szolgáltató dokumentációjának Példánygyorsítótár című szakaszát.

Feljegyzés

A példánygyorsítótárak minden nyelvi SDK-ban működnek, de ez a CacheOrchestrationCursors lehetőség csak a folyamaton belüli .NET-feldolgozó számára érhető el.

Egyidejűségi szabályozások

Egyetlen feldolgozópéldány egyszerre több munkaelemet is végrehajthat. Ez segít a párhuzamosság növelésében és a dolgozók hatékonyabb kihasználásában. Ha azonban egy feldolgozó túl sok munkaelemet próbál egyszerre feldolgozni, az kimerítheti a rendelkezésre álló erőforrásokat, például a processzorterhelést, a hálózati kapcsolatok számát vagy a rendelkezésre álló memóriát.

Annak érdekében, hogy az egyes feldolgozók ne legyenek túlkompatinálva, szükség lehet a példányonkénti egyidejűség szabályozására. Az egyes feldolgozókon egyidejűleg futó függvények számának korlátozásával elkerülhetjük az adott feldolgozó erőforráskorlátainak kimerítését.

Feljegyzés

Az egyidejűségi szabályozások csak helyileg alkalmazhatók, hogy korlátozva legyen a jelenleg feldolgozónként feldolgozott adatok száma. Így ezek a szabályozások nem korlátozzák a rendszer teljes átviteli sebességét.

Tipp.

Bizonyos esetekben a feldolgozónkénti egyidejűség szabályozása ténylegesen növelheti a rendszer teljes átviteli sebességét. Ez akkor fordulhat elő, ha minden egyes feldolgozó kevesebb munkát vesz igénybe, ami azt eredményezi, hogy a méretezési vezérlő több feldolgozót ad hozzá, hogy lépést tartson az üzenetsorokkal, ami növeli a teljes átviteli sebességet.

Szabályozások konfigurálása

A tevékenység-, vezénylési és entitásfüggvények egyidejűségi korlátai konfigurálhatók a host.json fájlban. A vonatkozó beállítások a tevékenységfüggvényekre durableTask/maxConcurrentActivityFunctions , valamint durableTask/maxConcurrentOrchestratorFunctions a vezénylési és az entitásfüggvényekre is vonatkozik. Ezek a beállítások szabályozzák az egyetlen feldolgozó memóriájába betöltött vezénylő, entitás vagy tevékenységfüggvények maximális számát.

Feljegyzés

A vezénylések és entitások csak akkor töltődnek be a memóriába, ha aktívan dolgozzák fel az eseményeket vagy műveleteket, vagy ha a példány gyorsítótárazása engedélyezve van. Miután végrehajtotta a logikát, és várta (pl. egy await (C#) vagy yield (JavaScript, Python) utasítást a vezénylési függvény kódjában, lehet, hogy ki lesznek ürítve a memóriából. A memóriából kipakolt vezénylések és entitások nem számítanak bele a maxConcurrentOrchestratorFunctions szabályozásba. Még ha több millió vezénylés vagy entitás is "Fut" állapotban van, akkor is csak akkor számolnak a szabályozás korlátja felé, amikor betöltik őket az aktív memóriába. A tevékenységfüggvényeket hasonlóképpen ütemező vezénylés nem számít bele a szabályozásba, ha a vezénylés arra vár, hogy a tevékenység befejeződjön.

Functions 2.0

{
  "extensions": {
    "durableTask": {
      "maxConcurrentActivityFunctions": 10,
      "maxConcurrentOrchestratorFunctions": 10
    }
  }
}

Functions 1.x

{
  "durableTask": {
    "maxConcurrentActivityFunctions": 10,
    "maxConcurrentOrchestratorFunctions": 10
  }
}

Nyelvi futtatókörnyezeti szempontok

A választott nyelvi futtatókörnyezet szigorú egyidejűségi korlátozásokat vagy függvényeket írhat elő. A Pythonban vagy a PowerShellben írt Durable Functions-alkalmazások például csak egyetlen függvény egyidejű futtatását támogathatják egyetlen virtuális gépen. Ez jelentős teljesítményproblémákhoz vezethet, ha nem gondosan számolunk el. Ha például egy vezénylő 10 tevékenységet támogat, de a nyelvi futtatókörnyezet csak egy függvényre korlátozza az egyidejűséget, akkor a 10 tevékenységfüggvényből 9 elakad a futtatásra várva. Továbbá ez a 9 elakadt tevékenység nem lesz képes más feldolgozók számára kiosztani a terhelést, mert a Durable Functions-futtatókörnyezet már betöltötte őket a memóriába. Ez különösen akkor válik problémássá, ha a tevékenységfüggvények hosszú ideig futnak.

Ha az ön által használt nyelvi futtatókörnyezet korlátozza az egyidejűséget, frissítenie kell a Durable Functions egyidejűségi beállításait, hogy megfeleljenek a nyelvi futtatókörnyezet egyidejűségi beállításainak. Ez biztosítja, hogy a Durable Functions-futtatókörnyezet ne kíséreljen meg egyszerre több függvényt futtatni, mint amennyit a nyelvi futtatókörnyezet engedélyez, így a függőben lévő tevékenységek terhelése kiegyensúlyozható a többi virtuális géppel. Ha például olyan Python-alkalmazással rendelkezik, amely 4 függvényre korlátozza az egyidejűséget (lehet, hogy csak 4 szál van konfigurálva egyetlen nyelvi feldolgozó folyamaton, vagy 1 szál 4 nyelvi feldolgozó folyamaton), akkor mindkettőt maxConcurrentOrchestratorFunctions és maxConcurrentActivityFunctions 4-et is konfigurálnia kell.

A Pythonra vonatkozó további információkért és teljesítményjavaslatokért lásd: A Python-alkalmazások átviteli sebességének javítása az Azure Functionsben. A Python fejlesztői referenciadokumentációjában említett technikák jelentős hatással lehetnek a Durable Functions teljesítményére és méretezhetőségére.

Partíciók száma

Egyes tárolószolgáltatók particionálási mechanizmust használnak, és lehetővé teszik egy paraméter megadásátpartitionCount.

Particionálás használatakor a dolgozók nem versenyeznek közvetlenül az egyes munkaelemekért. Ehelyett a munkaelemek először partíciókba partitionCount vannak csoportosítva. Ezek a partíciók ezután a feldolgozókhoz lesznek rendelve. A terheléselosztás particionált megközelítése segíthet csökkenteni a szükséges tárelérések teljes számát. Emellett engedélyezheti a példányok gyorsítótárazását és javíthatja a helységet, mert affinitást hoz létre: az ugyanazon példányhoz tartozó összes munkaelemet ugyanaz a feldolgozó dolgozza fel.

Feljegyzés

A particionálási korlátok felskálázhatók, mert a legtöbb partitionCount feldolgozó feldolgozhatja a munkaelemeket egy particionált üzenetsorból.

Az alábbi táblázat az egyes tárolószolgáltatók esetében megjeleníti a particionált üzenetsorokat, valamint a paraméter megengedett tartományát és alapértelmezett értékeit partitionCount .

	Azure Storage-szolgáltató	Netherite storage provider	MSSQL-tárolószolgáltató
Példányüzenetek	Partitioned	Partitioned	Nincs particionált
Tevékenységüzenetek	Nincs particionált	Partitioned	Nincs particionált
Alapértelmezett partitionCount	4	12	n.a.
Maximális partitionCount	16	32	n.a.
Documentation	Lásd: Orchestrator scale-out	Lásd a partíciók számának szempontjait	n.a.

Figyelmeztetés

A partíciók száma a tevékenységközpont létrehozása után már nem módosítható. Ezért célszerű olyan nagy értékre beállítani, amely megfelel a feladatközpont-példány jövőbeli vertikális felskálázási követelményeinek.

A partíciók számának konfigurálása

A partitionCount paraméter a host.json fájlban adható meg. Az alábbi példa host.json kódrészlet a tulajdonságot (vagy durableTask/partitionCount a durableTask/storageProvider/partitionCount Durable Functions 1.x-ben) a következőre 3állítja.

Durable Functions 2.x

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

Durable Functions 1.x

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

Megfontolandó szempontok a meghívási késések minimalizálása érdekében

Normál körülmények között a meghívási kéréseket (tevékenységekhez, vezénylőkhöz, entitásokhoz stb.) elég gyorsan kell feldolgozni. A híváskérések maximális késésére azonban nincs garancia, mivel az olyan tényezőktől függ, mint például az App Service-csomag skálázási viselkedésének típusa, az egyidejűségi beállítások és az alkalmazás hátralékának mérete. Ezért azt javasoljuk, hogy a stressztesztelésbe fektetve mérje és optimalizálja az alkalmazás késéseit.

Teljesítménycélok

Amikor a Durable Functionst éles alkalmazásokhoz tervezi használni, fontos, hogy a tervezési folyamat korai szakaszában figyelembe vegye a teljesítménykövetelményeket. Néhány alapvető használati forgatókönyv:

• Szekvenciális tevékenység végrehajtása: Ez a forgatókönyv egy olyan vezénylő függvényt ír le, amely egymás után futtatja a tevékenységfüggvények sorozatát. Leginkább a függvényláncolás mintájára hasonlít.
• Párhuzamos tevékenységvégrehajtás: Ez a forgatókönyv egy olyan vezénylő függvényt ír le, amely számos tevékenységfüggvényt hajt végre párhuzamosan a fan-out, fan-in minta használatával.
• Párhuzamos válaszfeldolgozás: Ez a forgatókönyv a fan-out, fan-in minta második fele. A ventilátorok teljesítményére összpontosít. Fontos megjegyezni, hogy a fan-outtól eltérően a ventilátort egyetlen vezénylő függvénypéldány végzi, ezért csak egyetlen virtuális gépen futtatható.
• Külső eseményfeldolgozás: Ez a forgatókönyv egyetlen vezénylőfüggvénypéldányt jelöl, amely egyenként várakozik a külső eseményekre.
• Entitásművelet feldolgozása: Ez a forgatókönyv azt teszteli, hogy egy számláló entitás milyen gyorsan tudja feldolgozni a műveletek állandó adatfolyamát.

Ezekhez a forgatókönyvekhez az átviteli sebességszámokat a társzolgáltatók megfelelő dokumentációjában biztosítjuk. Elsősorban:

• az Azure Storage-szolgáltató esetében lásd a teljesítménycélokat.
• a Netherite storage-szolgáltató esetében lásd az alapforgatókönyveket.
• az MSSQL-tárolószolgáltató esetében lásd az Orchestration Throughput Benchmarks (Vezénylési átviteli sebesség teljesítménymutatói) című témakört.

Tipp.

A kifúvatástól eltérően a ventilátorok üzemeltetése egyetlen virtuális gépre korlátozódik. Ha az alkalmazás a ki- és beszívó mintát használja, és aggódik a ventilátorok teljesítménye miatt, fontolja meg a tevékenységfüggvény több rész vezénylésre való felosztását.

Következő lépések

Az Azure Storage-szolgáltató ismertetése