Kontrolní seznam efektivity výkonu

Efektivita výkonu je schopnost vaší úlohy škálovat se tak, aby efektivně splňovala požadavky uživatelů, a je jedním z pilířů Microsoft Azure Well-Architected Frameworku. Pomocí tohoto kontrolního seznamu můžete zkontrolovat architekturu aplikace z hlediska efektivity výkonu.

Návrh aplikací

Rozdělte úlohu na oddíly. Navrhovat části procesu tak, aby byly diskrétní a rozložitelné. Minimalizujte velikost každé části a přitom do souladu s obvyklými pravidly pro oddělení obav a principu jedné odpovědnosti. To umožňuje distribuci částí komponent způsobem, který maximalizuje využití jednotlivých výpočetních jednotek (například role nebo databázového serveru). Usnadňuje také škálování aplikace přidáním instancí konkrétních prostředků. V případě složitých domén zvažte použití architektury mikroslužeb.

Navrhovat pro škálování. Škálování umožňuje aplikacím reagovat na proměnlivé zatížení zvýšením a snížením počtu instancí rolí, front a dalších služeb, které používají. Aplikace ale musí být navržena s vědomím. Například aplikace a služby, které používá, musí být bez stavu, aby bylo možné směrovat požadavky na libovolnou instanci. To také brání přidání nebo odebrání konkrétních instancí, aby to nepříznivě ovlivnilo aktuální uživatele. Měli byste také implementovat konfiguraci nebo automatické detetection instancí při jejich přidání a odebrání, aby kód v aplikaci mohl provést potřebné směrování. Webová aplikace může například pomocí sady front s kruhovým dotazování směrovat požadavky na služby na pozadí spuštěné v rolích pracovního procesu. Webová aplikace musí být schopná rozpoznat změny v počtu front, aby mohla úspěšně směrovat požadavky a vyvážit zatížení aplikace.

Škálování jako jednotky Naplánujte další prostředky pro přizpůsobení růstu. U každého prostředku znají horní limity škálování a pomocí shardování nebo rozkladu tyto limity překračují. Určete jednotky škálování systému z hlediska jasně definovaných sad prostředků. To usnadňuje použití operací škálování na více systémů a méně náchylné k negativnímu dopadu na aplikaci prostřednictvím omezení stanovených nedostatkem prostředků v některé části celkového systému. Například přidání „x“ webových a pracovních rolí může vyžadovat „y“ dalších front a „z“ účtů úložiště pro zpracování dodatečného zatížení vygenerovaného rolemi. Jednotka škálování by se tak mohla skládat z x webových a pracovních rolí, front y a účtů úložiště z. Navrhněte aplikaci tak, aby se snadno škálovala přidáním jedné nebo více jednotek škálování. Zvažte nasazení jednotek škálování pomocí modelu Nasazování razítek.

Vyhněte se spřažení klienta. Pokud je to možné, ujistěte se, že aplikace nevyžaduje spřažení. Požadavky lze proto směrovat na libovolnou instanci a počet instancí je irelevantní. Tím se také zabrání režii při ukládání, načítání a údržbě informací o stavu pro jednotlivé uživatele.

Využijte výhod funkcí automatického škálování platformy. Tam, kde hostingová platforma podporuje funkci automatického škálování, jako je automatické škálování Azure, upřednostňte ji před vlastními mechanismy nebo mechanismy třetích stran, pokud integrovaný mechanismus nemůže splnit vaše požadavky. Pokud je to možné, použijte plánovaná pravidla škálování, abyste zajistili, že prostředky budou k dispozici bez zpoždění při spuštění, ale pokud je to vhodné, přidejte do pravidel reaktivní automatické škálování, abyste se dokázali vypořádat s neočekávanými změnami v poptávce. Operace automatického škálování v modelu nasazení Classic můžete použít k úpravě automatického škálování a k přidání vlastních čítačů do pravidel. Další informace najdete v tématu Pokyny pro automatické škálování.

Přenačte úlohy náročné na procesor a náročné na V/V jako úlohy na pozadí. Pokud se očekává, že spuštění požadavku na službu nebo absorbování značných prostředků trvá dlouho, převezměte zpracování tohoto požadavku na samostatnou úlohu. K provedení těchto úloh použijte role pracovního procesu nebo úlohy na pozadí (v závislosti na hostitelské platformě). Tato strategie umožňuje službě pokračovat v přijímání dalších požadavků a zůstat responzivní. Další informace najdete v tématu Doprovodné informace k úlohách na pozadí.

Distribuujte úlohu pro úlohy na pozadí. Pokud existuje mnoho úloh na pozadí nebo úkoly vyžadují značnou dobu nebo prostředky, rozdělte práci mezi několik výpočetních jednotek (například role pracovních procesů nebo úlohy na pozadí). Jedno z možných řešení najdete v tématu Model konkurujících si spotřebitelů.

Zvažte přechod na architekturu SN (Shared-Nothing). Architektura SN (Shared-Nothing) používá nezávislé a soběstačné uzly, které nemají žádný jediný bod kolektu (například sdílené služby nebo úložiště). Teoreticky může takový systém škálovat téměř na neomezenou dobu. I když přístup s plně sdíleným nic není pro většinu aplikací obecně praktický, může poskytnout příležitosti k návrhu pro lepší škálovatelnost. Dobrými příklady přechodu k architektuře SN (Shared-Nothing) je například vyhnout se použití stavu relace na straně serveru, spřažení klienta a dělení dat.

Správa dat

Použijte dělení dat. Rozdělte data mezi několik databází a databázových serverů nebo navrhovat aplikaci tak, aby s využitím služeb úložiště dat poskytovala toto dělení transparentně (mezi příklady patří Azure SQL Database elastická databáze a Azure Table Storage). Tento přístup může pomoct maximalizovat výkon a usnadnit škálování. Existují různé techniky dělení, jako jsou horizontální, vertikální a funkční. Jejich kombinací můžete dosáhnout maximálního užitku z vyššího výkonu dotazů, jednodušší škálovatelnosti, flexibilnější správy, lepší dostupnosti a spárování typu úložiště s daty, která budou uchovávat. Zvažte také použití různých typů úložiště dat pro různé typy dat a zvolte typy podle toho, jak dobře jsou optimalizované pro konkrétní typ dat. To může zahrnovat použití úložiště tabulek, databáze dokumentů nebo úložiště dat rodin sloupců místo nebo stejně jako relační databáze. Další informace najdete v tématu Pokyny k dělení dat.

Navrhovat pro případnou konzistenci. Případná konzistence zlepšuje škálovatelnost zkrácení nebo odebráním času potřebného k synchronizaci souvisejících dat rozdělených mezi více úložišť. Náklady jsou, že data nejsou při čtení vždy konzistentní a některé operace zápisu mohou způsobovat konflikty. Případná konzistence je ideální v situacích, kdy se stejná data čtou často, ale zapisová se jen zřídka. Další informace najdete v tématu Základy konzistence dat.

Omezte komunikaci mezi komponentami a službami. Vyhněte se návrhu interakcí, ve kterých aplikace musí provádět více volání služby (z nichž každé vrací malé množství dat), místo jednoho volání, které může vracet všechna data. Pokud je to možné, zkombinujte několik souvisejících operací do jednoho požadavku, pokud je volání služby nebo komponenty, která má znatelnou latenci. To usnadňuje monitorování výkonu a optimalizaci složitých operací. Například uložené procedury v databázích můžete použít k zapouzdření složité logiky a snížení počtu cest a zamykání prostředků.

K vyrovnání zatížení pro vysokorychlostní zápisy dat použijte fronty. Zvýšení poptávky po službě může zahltit službu a způsobit eskalaci selhání. Pokud tomu chcete zabránit, zvažte implementaci modelu vyrovnávání zatížení na základě fronty. Použijte frontu, která funguje jako vyrovnávací paměť mezi úlohou a službou, kterou vyvolá. Může tak dopadnout přerušované vysoké zatížení, které by jinak mohlo způsobit selhání služby nebo časový limit úlohy.

Minimalizujte zatížení úložiště dat. Úložiště dat je obvykle kritickým bodem zpracování, nákladným zdrojem a často není snadné škálovat na více než jednu z těchto 5 000 000 prostředků. Pokud je to možné, odeberte z úložiště dat logiku (například zpracování dokumentů XML nebo objektů JSON) a proveďte zpracování v rámci aplikace. Například místo předání XML do databáze (jiné než jako neprůhledný řetězec pro úložiště), serializovat nebo deserializovat XML v rámci aplikační vrstvy a předat jej ve formuláři, který je nativní pro úložiště dat. Obvykle je mnohem jednodušší škálovat aplikaci na více než úložiště dat, takže byste se měli pokusit v rámci aplikace provést co nejvíce zpracování náročné na výpočetní výkon.

Minimalizujte objem načtených dat. Načtěte pouze data, která požadujete, zadáním sloupců a použitím kritérií pro výběr řádků. Využijte parametry hodnoty tabulky a příslušnou úroveň izolace. Pokud se chcete vyhnout zbytečnému načítání dat, používejte mechanismy, jako jsou značky entit.

Agresivně používejte ukládání do mezipaměti. Ukládání do mezipaměti používejte všude, kde je to možné, abyste snížili zatížení prostředků a služeb, které generují nebo doručují data. Ukládání do mezipaměti je obvykle vhodný pro data, která jsou relativně statická nebo která k získání vyžadují značné zpracování. Ukládání do mezipaměti by mělo procházet na všech úrovních, kde je to vhodné v každé vrstvě aplikace, včetně přístupu k datům a generování uživatelského rozhraní. Další informace najdete v článku o ukládání do mezipaměti.

Zvládáte růst a uchování dat. Množství dat uložených aplikací se v průběhu času zvětšuje. Tento růst zvyšuje náklady na úložiště a také latenci při přístupu k datům, což má vliv na propustnost a výkon aplikace. Je možné pravidelně archivovat některá stará data, která už nejsou přístupná, nebo přesouvat zřídka nízká data do dlouhodobého úložiště, které je nákladově efektivnější, i když je latence přístupu vyšší.

Optimalizujte objekty DTO (Data Transfer Objects) pomocí efektivního binárního formátu. Objekty DTO se mnohokrát předá mezi vrstvami aplikace. Minimalizace velikosti snižuje zatížení prostředků a sítě. Vyvažte ale úspory s režií při převodu dat na požadovaný formát v každém umístění, kde se používají. Použijte formát, který má maximální interoperabilitu, aby bylo možné snadno opakovaně používat komponentu.

Nastavte ovládací prvek mezipaměti. Pokud je to možné, navrhujte a nakonfigurujte aplikaci pro použití ukládání výstupu do mezipaměti nebo ukládání fragmentů do mezipaměti, aby se minimalizovala zátěž při zpracování.

Povolte ukládání do mezipaměti na straně klienta. Webové aplikace by měly povolit nastavení mezipaměti pro obsah, který může být uložen do mezipaměti. Ve výchozím nastavení je to obvykle zakázáno. Nakonfigurujte server tak, aby poskytoval příslušné hlavičky kontrolních hlaviček mezipaměti, aby bylo možné ukládat obsah do mezipaměti na proxy serverech a klientech.

k omezení zatížení aplikace použijte azure blob storage a Azure Content Delivery Network. V úložišti objektů blob můžete ukládat statický nebo poměrně statický veřejný obsah, jako jsou obrázky, prostředky, skripty a šablony stylů. Tento přístup zbavuje aplikaci zátěže, která je způsobena dynamickým generováním tohoto obsahu pro každý požadavek. kromě toho zvažte použití Content Delivery Network k ukládání tohoto obsahu do mezipaměti a jejich doručování klientům. použití Content Delivery Network může zlepšit výkon u klienta, protože obsah je dodáván z geograficky nejbližšího datového centra, které obsahuje mezipaměť Content Delivery Network. další informace najdete v tématu pokyny pro Content Delivery Network.

optimalizujte a optimalizujte SQL dotazy a indexy. některé příkazy T-SQL nebo konstrukce mohou mít nežádoucí vliv na výkon, který lze snížit optimalizací kódu v uložené proceduře. Například Vyhněte se převodu typů DateTime na typ varchar před porovnáním s hodnotou literálu DateTime . Místo toho použijte funkce porovnání data a času. Nedostatek odpovídajících indexů může také zpomalit provádění dotazů. Použijete-li objekt nebo relační mapové rozhraní, zjistěte, jak funguje a jak může ovlivnit výkon vrstvy přístupu k datům. Další informace najdete v tématu ladění dotazů.

Zvažte denormalizaci dat. Normalizace dat pomáhá vyhnout se duplicitám a nekonzistenci. Avšak údržba více indexů, kontrola referenční integrity, vícenásobné přístupy k malým blokům dat a spojování tabulek za účelem revýšení dat, ukládá režii, která může ovlivnit výkon. Vezměte v úvahu, zda je k omezení zatížení úložiště dat přijatelné některé další svazky úložiště a duplicity. Zvažte také, zda je možné přebírat úkoly, jako je například Správa referenční integrity za účelem snížení zatížení úložiště dat, v případě, že je samotná aplikace (což je obvykle snazší škálování). Další informace najdete v tématu pokyny k dělení dat.

Implementace

Přečtěte si antipatterny výkonu. Běžné postupy, které mohou způsobovat problémy se škálovatelností v případě, že dojde k vytlaku aplikace, najdete v článku antipatterny výkonu pro cloudové aplikace .

Použijte asynchronní volání. Použijte asynchronní kód, kdykoli je to možné, při přístupu k prostředkům nebo službám, které mohou být omezeny pomocí vstupně-výstupních operací nebo šířky pásma sítě nebo které mají znatelné latenci, aby nedošlo k uzamknutí volajícího vlákna.

Vyhněte se uzamykání prostředků a místo toho používejte optimistický přístup. Nikdy nepoužívejte přístup k prostředkům, jako jsou například úložiště nebo jiné služby, které mají znatelné latence, protože jde o primární příčinu špatného výkonu. Pro správu souběžných operací, jako je například zápis do úložiště, používejte vždy optimistické přístupy. Ke správě konfliktů použijte funkce vrstvy úložiště. V distribuovaných aplikacích mohou být data pouze nakonec konzistentní.

Komprimovat vysoce komprimovat data přes vysokou latenci a sítě s nízkou šířkou pásma. Ve většině případů webové aplikace je největší objem dat generovaný aplikací a předaných přes síť odpověďmi HTTP na požadavky klientů. Komprese HTTP se může významně snížit, zejména pro statický obsah. To může snížit náklady i snížit zatížení sítě, i když komprimace dynamického obsahu aplikuje na server zlomně vyšší zatížení. V ostatních, obecnější prostředích může komprese dat snížit objem přenášených dat a minimalizovat čas a náklady na přenos, ale procesy komprese a dekomprese se účtují režií. Komprese by se měla používat jenom v případě, že dojde k prokazatelně získanému nárůstu výkonu. Jiné metody serializace, jako je JSON nebo binární kódování, mohou snížit velikost datové části a přitom mít méně vliv na výkon, zatímco XML je pravděpodobně zvýší.

Minimalizujte čas, kdy se připojení a prostředky používají. Udržujte připojení a prostředky jenom za předpokladu, že je potřebujete použít. Například otevřete připojení co nejrychleji a umožněte, aby byly vráceny do fondu připojení co nejdříve. Získejte prostředky co nejrychleji a co nejdříve je vyřadit.

Minimalizujte počet požadovaných připojení. Připojení služby pohlcování prostředků. Omezte počet požadovaných požadavků a zajistěte, aby byla existující připojení znovu používána, kdykoli to bude možné. Například po provedení ověření použijte zosobnění, kde je vhodné spustit kód jako konkrétní identitu. To vám může pomoci využít fond připojení znovu pomocí připojení.

Odeslání požadavků v dávkách za účelem optimalizace využití sítě. Můžete například posílat a číst zprávy v dávkách při přístupu k frontě a při přístupu k úložišti nebo mezipaměti provádět vícenásobné čtení nebo zápisy. To může přispět k maximalizaci efektivity služeb a úložišť dat tím, že se sníží počet volání v síti.

Vyhněte se nutnosti ukládat stav relace na straně serveru , pokud je to možné. Správa stavu relace na straně serveru obvykle vyžaduje spřažení klienta (to znamená směrování jednotlivých požadavků na stejnou instanci serveru), což má vliv na schopnost škálování systému. V ideálním případě byste měli navrhovat klienty bez příslušnosti v souvislosti se servery, které používají. Pokud však aplikace musí zachovat stav relace, ukládejte citlivá data nebo velké objemy dat pro jednotlivé klienty v distribuované mezipaměti na straně serveru, ke které mají přístup všechny instance aplikace.

Optimalizujte schémata úložiště tabulek. Pokud používáte obchody s tabulkami, které vyžadují předávat a zpracovávat názvy tabulek a sloupců s každým dotazem, jako je Azure Table Storage, zvažte použití kratších názvů, abyste snížili režii. Nepoužívejte však oprávnění ke čtení ani spravovatelnost pomocí s více kompaktními názvy.

Vytvořte závislosti prostředků během nasazování nebo při spuštění aplikace. Vyhněte se Opakovaným voláním metod, které testují existenci prostředku, a pak vytvořte prostředek, pokud neexistuje. tento model se řídí metodami, jako je například clouda. CreateIfNotExists a CloudQueue. CreateIfNotExists v klientské knihovně Azure Storage. Tyto metody mohou způsobit značnou režii, pokud jsou vyvolány před každým přístupem k tabulce úložiště nebo frontou úložiště. Takové

• Vytvoření požadovaných prostředků při nasazení aplikace nebo při prvním spuštění (jedno volání CreateIfNotExists pro každý prostředek ve spouštěcím kódu pro web nebo roli pracovního procesu je přijatelné). Nicméně nezapomeňte zpracovat výjimky, které mohou nastat, pokud se váš kód pokusí o přístup k prostředku, který neexistuje. V těchto situacích byste měli zaznamenat výjimku a případně upozornit operátora, že prostředek chybí.
• Za určitých okolností může být vhodné vytvořit chybějící prostředek jako součást kódu zpracování výjimek. Ale měli byste tento přístup přijmout opatrně, protože neexistence prostředku může znamenat chybu při programování (například název prostředku, který je špatně napsaný), nebo nějaký jiný problém na úrovni infrastruktury.

Používejte odlehčené architektury. Pečlivě vyberte rozhraní API a rozhraní, která používáte k minimalizaci využití prostředků, doby spuštění a celkovému zatížení aplikace. například použití webového rozhraní API pro zpracování žádostí o služby může snížit nároky na aplikace a zvýšit rychlost spuštění, ale nemusí být vhodné pro pokročilé scénáře, kde jsou požadovány další možnosti Windows Communication Foundation.

Zvažte minimalizaci počtu účtů služeb. Například použijte konkrétní účet pro přístup k prostředkům nebo službám, které omezují připojení, nebo lepší, když je udržováno menší množství připojení. Tento přístup je společný pro služby, jako jsou databáze, ale může ovlivnit schopnost přesně provádět operace auditu z důvodu zosobnění původního uživatele.

Proveďte profilaci výkonu a zátěžové testování během vývoje, jako součást testovacích rutin a před finální verzí, abyste zajistili, že aplikace funguje a bude podle potřeby škálovaná. Toto testování by se mělo provádět na stejném typu hardwaru jako produkční platforma a se stejnými typy a množstvím dat a uživatelským zatížením, jak se bude nacházet v produkčním prostředí. Další informace najdete v tématu testování výkonu cloudové služby.