Kontrolní seznam výkonu a škálovatelnosti pro Queue Storage

Společnost Microsoft vyvinula mnoho osvědčených postupů pro vývoj vysoce výkonných aplikací pomocí queue Storage. Tento kontrolní seznam identifikuje klíčové postupy, které můžou vývojáři sledovat za účelem optimalizace výkonu. Mějte tyto postupy na paměti při navrhování aplikace a v průběhu celého procesu.

Azure Storage má škálovatelnost a cíle výkonu pro kapacitu, rychlost transakcí a šířku pásma. Další informace o cílech škálovatelnosti služby Azure Storage najdete v tématu Škálovatelnost a výkonnostní cíle pro standardní účty úložiště a škálovatelnost a výkonnostní cíle pro Queue Storage.

Kontrolní seznam

Tento článek organizuje osvědčené postupy pro výkon do kontrolního seznamu, který můžete sledovat při vývoji aplikace Queue Storage.

Cíle škálovatelnosti

Pokud vaše aplikace přistupuje nebo překračuje některý z cílů škálovatelnosti, může nastat zvýšená latence transakcí nebo omezování. Když Azure Storage omezí vaši aplikaci, služba začne vracet kódy chyb 503 (Server Busy) nebo 500 (Operation Timeout). Zabránění těmto chybám tím, že zůstanete v mezích cílů škálovatelnosti, je důležitou součástí zvýšení výkonu vaší aplikace.

Další informace o cílech škálovatelnosti pro Queue Storage najdete v tématu Škálovatelnost a výkonnostní cíle služby Azure Storage.

Maximální počet účtů úložiště

Pokud se blížíte maximálnímu počtu účtů úložiště povolených pro konkrétní kombinaci předplatného nebo oblasti, používáte k horizontálnímu dělení více účtů úložiště ke zvýšení příchozího přenosu dat, výchozího přenosu dat, vstupně-výstupních operací za sekundu (IOPS) nebo kapacity? V tomto scénáři Microsoft doporučuje, abyste využili zvýšené limity pro účty úložiště, abyste snížili počet účtů úložiště potřebných pro vaši úlohu, pokud je to možné. Obraťte se na podporu Azure a požádejte o zvýšené limity pro váš účet úložiště.

Cíle kapacity a transakcí

Pokud vaše aplikace přistupuje k cílům škálovatelnosti pro jeden účet úložiště, zvažte použití jednoho z následujících přístupů:

• Pokud cíle škálovatelnosti pro fronty nejsou pro vaši aplikaci dostatečné, použijte více front a distribuujte mezi ně zprávy.
• Znovu zvažte úlohu, která způsobí, že vaše aplikace bude přistupovat k cíli škálovatelnosti nebo ji překročit. Můžete ji navrhnout jinak, aby používala menší šířku pásma nebo kapacitu nebo méně transakcí?
• Pokud vaše aplikace musí překročit jeden z cílů škálovatelnosti, vytvořte několik účtů úložiště a rozdělte data aplikace mezi tyto více účtů úložiště. Pokud použijete tento vzor, nezapomeňte navrhnout aplikaci tak, abyste v budoucnu mohli přidat další účty úložiště pro vyrovnávání zatížení. Účty úložiště nemají jiné náklady než vaše využití z hlediska uložených dat, transakcí nebo přenášených dat.
• Pokud se vaše aplikace blíží cílům šířky pásma, zvažte komprimaci dat na straně klienta, abyste snížili šířku pásma potřebnou k odesílání dat do Azure Storage. Komprese dat sice může šetřit šířku pásma a zlepšit výkon sítě, ale může mít také negativní vliv na výkon. Vyhodnoťte dopad na výkon dalších požadavků na zpracování pro kompresi a dekompresi dat na straně klienta. Mějte na paměti, že ukládání komprimovaných dat může ztížit řešení potíží, protože může být obtížnější zobrazit data pomocí standardních nástrojů.
• Pokud se vaše aplikace blíží cílům škálovatelnosti, ujistěte se, že pro opakování používáte exponenciální zpochybňování. Nejlepší je se pokusit vyhnout se dosažení cílů škálovatelnosti implementací doporučení popsaných v tomto článku. Použití exponenciálního omezení opakování však brání vaší aplikaci v rychlém opakování, což by mohlo zhoršit omezování. Další informace najdete v části Chyby vypršení časového limitu a zaneprázdnění serveru.

Sítě

Omezení fyzické sítě aplikace můžou mít významný dopad na výkon. Následující části popisují některá omezení, se kterými se můžou uživatelé setkat.

Funkce klientské sítě

Šířka pásma a kvalita síťového propojení hrají důležité role při výkonu aplikace, jak je popsáno v následujících částech.

Propustnost

U šířky pásma je problém často schopností klienta. Větší instance Azure mají síťové karty s větší kapacitou, takže pokud potřebujete vyšší limity sítě z jednoho počítače, měli byste zvážit použití větší instance nebo více virtuálních počítačů. Pokud přistupujete ke službě Azure Storage z místní aplikace, platí stejné pravidlo: seznamte se se síťovými funkcemi klientského zařízení a síťového připojení k umístění Azure Storage a buď je podle potřeby vylepšete, nebo navrhněte aplikaci tak, aby fungovala v rámci svých možností.

Kvalita propojení

Stejně jako u jakéhokoli použití sítě mějte na paměti, že síťové podmínky, které vedou k chybám a ztrátě paketů, zpomaluje efektivní propustnost. S diagnostikou tohoto problému vám může pomoct použití wiresharku nebo monitorování sítě.

Poloha

V jakémkoli distribuovaném prostředí poskytuje klient blízko serveru nejlepší výkon. Pro přístup ke službě Azure Storage s nejnižší latencí je nejlepší umístění pro vašeho klienta ve stejné oblasti Azure. Pokud máte například webovou aplikaci Azure, která používá Azure Storage, vyhledejte je v jedné oblasti, například v oblasti USA – západ nebo Jihovýchodní Asie. Společné umístění prostředků snižuje latenci a náklady, protože využití šířky pásma v rámci jedné oblasti je bezplatné.

Pokud klientské aplikace přistupují ke službě Azure Storage, ale nejsou hostované v Rámci Azure, jako jsou aplikace mobilních zařízení nebo místní podnikové služby, může umístění účtu úložiště v oblasti blízko těchto klientů snížit latenci. Pokud jsou vaši klienti široce distribuovaná (například některé v Severní Amerika a některé v Evropě), zvažte použití jednoho účtu úložiště pro každou oblast. Tento přístup je jednodušší implementovat, pokud jsou data, která jsou úložiště aplikací specifická pro jednotlivé uživatele, a nevyžaduje replikaci dat mezi účty úložiště.

SAS a CORS

Předpokládejme, že potřebujete autorizovat kód, jako je JavaScript, který běží ve webovém prohlížeči uživatele nebo v mobilní aplikaci pro přístup k datům ve službě Azure Storage. Jedním z přístupů je vytvoření aplikace služby, která funguje jako proxy server. Zařízení uživatele se ověřuje ve službě, která pak autorizuje přístup k prostředkům Azure Storage. Tímto způsobem se můžete vyhnout zveřejnění klíčů účtu úložiště na nezabezpečených zařízeních. Tento přístup ale výrazně zatěžuje aplikaci služby, protože všechna data přenášená mezi zařízením uživatele a službou Azure Storage musí projít aplikací služby.

Použití aplikace služby jako proxy serveru pro Azure Storage můžete zabránit pomocí sdílených přístupových podpisů (SAS). Pomocí sdíleného přístupového podpisu můžete povolit, aby zařízení uživatele mohly provádět požadavky přímo do Služby Azure Storage pomocí omezeného přístupového tokenu. Pokud například chce uživatel nahrát fotku do aplikace, může aplikace služby vygenerovat SAS a odeslat ji do zařízení uživatele. Token SAS může udělit oprávnění k zápisu do prostředku služby Azure Storage po zadaný časový interval, po jehož uplynutí platnost tokenu SAS vyprší. Další informace o SAS najdete v tématu Udělení omezeného přístupu k prostředkům Azure Storage pomocí sdílených přístupových podpisů (SAS).

Webový prohlížeč obvykle nepovolí JavaScript na stránce hostované webem v jedné doméně k provádění určitých operací, jako jsou operace zápisu, do jiné domény. Tato zásada označovaná jako zásada stejného původu brání škodlivému skriptu na jedné stránce v získání přístupu k datům na jiné webové stránce. Zásady stejného původu ale můžou být omezením při vytváření řešení v cloudu. Sdílení prostředků mezi zdroji (CORS) je funkce prohlížeče, která cílové doméně umožňuje komunikovat s prohlížečem, kterému důvěřuje požadavkům pocházejícím ze zdrojové domény.

Předpokládejme například, že webová aplikace spuštěná v Azure vytvoří požadavek na prostředek do účtu Azure Storage. Webová aplikace je zdrojová doména a účet úložiště je cílová doména. CORS můžete nakonfigurovat pro libovolnou službu Azure Storage, která bude komunikovat s webovým prohlížečem, kterému služba Azure Storage důvěřuje, že požadavky ze zdrojové domény důvěřují. Další informace o CORS najdete v tématu Podpora sdílení prostředků mezi zdroji (CORS) pro Azure Storage.

Sas i CORS vám můžou pomoct vyhnout se zbytečnému zatížení webové aplikace.

Konfigurace .NET

V případě projektů používajících rozhraní .NET Framework uvádí tato část několik rychlých nastavení konfigurace, pomocí nichž můžete výrazně zlepšit výkon. Pokud používáte jiný jazyk než .NET, zkontrolujte, jestli se ve zvoleném jazyce používají podobné koncepty.

Zvýšení výchozího limitu připojení

U projektů používajících rozhraní .NET Framework můžete pomocí následujícího kódu zvýšit výchozí limit připojení (což je obvykle 2 v klientském prostředí nebo 10 v serverovém prostředí) na 100. Obvykle byste měli nastavit hodnotu na přibližně počet vláken používaných vaší aplikací. Před otevřením připojení nastavte limit připojení.

ServicePointManager.DefaultConnectionLimit = 100; //(Or More)  

Další informace o omezeních fondu připojení v rozhraní .NET Framework najdete v tématu o omezeních fondu rozhraní .NET Framework Připojení ion a nové sadě Azure SDK pro .NET.

Informace o nastavení limitu připojení najdete v dokumentaci.

Zvýšení minimálního počtu vláken

Pokud používáte synchronní volání společně s asynchronními úlohami, můžete zvýšit počet vláken ve fondu vláken:

ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)  

Další informace naleznete v ThreadPool.SetMinThreads metoda.

Nevázaný paralelismus

I když může být paralelismus skvělý pro výkon, buďte opatrní při používání nevázaného paralelismu, což znamená, že počet vláken nebo paralelních požadavků není nijak omezený. Nezapomeňte omezit paralelní požadavky na nahrání nebo stažení dat, přístup k více oddílům ve stejném účtu úložiště nebo přístup k více položkám ve stejném oddílu. Pokud je paralelismus nevázaný, může vaše aplikace překročit možnosti klientského zařízení nebo cíle škálovatelnosti účtu úložiště, což vede k delší latenci a omezování.

Klientské knihovny a nástroje

Pro zajištění nejlepšího výkonu vždy používejte nejnovější klientské knihovny a nástroje poskytované Microsoftem. Klientské knihovny Azure Storage jsou k dispozici pro různé jazyky. Azure Storage také podporuje PowerShell a Azure CLI. Microsoft aktivně vyvíjí tyto klientské knihovny a nástroje s ohledem na výkon, udržuje je v aktualizovaném stavu s nejnovějšími verzemi služeb a zajišťuje, aby zvládly řadu osvědčených postupů výkonu interně. Další informace najdete v referenční dokumentaci ke službě Azure Storage.

Zpracování chyb služby

Azure Storage vrátí chybu, když služba nemůže zpracovat požadavek. Pochopení chyb, které může azure Storage v daném scénáři vrátit, je užitečné pro optimalizaci výkonu.

Chyby vypršení časového limitu a zaneprázdnění serveru

Azure Storage může aplikaci omezovat, pokud se blíží limitům škálovatelnosti. V některých případech nemusí Azure Storage kvůli nějaké přechodné podmínce zpracovat požadavek. V obou případech může služba vrátit chybu 503 (Server Busy) nebo 500 (Timeout). K těmto chybám může dojít také v případě, že služba vyrovnává datové oddíly tak, aby umožňovala vyšší propustnost. Klientská aplikace by měla obvykle opakovat operaci, která způsobuje jednu z těchto chyb. Pokud ale Služba Azure Storage omezuje vaši aplikaci, protože překračuje cíle škálovatelnosti, nebo i když služba nemohla požadavek obsluhovat z nějakého jiného důvodu, může se problém zhoršovat agresivními opakováními. Použití exponenciálních zásad opakování se doporučuje a klientské knihovny se pro toto chování standardně používají. Vaše aplikace se například může opakovat po 2 sekundách, pak po 4 sekundách, 10 sekundách, pak po 30 sekundách a pak se úplně vzdát. Tímto způsobem vaše aplikace výrazně snižuje zatížení služby, místo aby zvýšila chování, které by mohlo vést k omezování.

Připojení chyby citlivosti je možné opakovat okamžitě, protože nejsou výsledkem omezování a očekává se, že budou přechodné.

Chyby, které se nedají opakovat

Klientské knihovny zpracovávají opakování s vědomím, které chyby je možné opakovat a které ne. Pokud ale rozhraní REST API služby Azure Storage voláte přímo, měli byste to zkusit znovu. Například chyba 400 (Bad Request) značí, že klientská aplikace odeslala požadavek, který se nepodařilo zpracovat, protože nebyl v očekávaném formátu. Opětovným odesláním tohoto požadavku se pokaždé zobrazí stejná odpověď, takže při opakování neexistuje žádný bod. Pokud rozhraní REST API služby Azure Storage voláte přímo, mějte na paměti potenciální chyby a to, jestli se mají opakovat.

Další informace o kódech chyb Azure Storage najdete v tématu Stav a kódy chyb.

Zakázání algoritmu Nagle

Algoritmus Nagle je široce implementovaný napříč sítěmi TCP/IP jako prostředek ke zlepšení výkonu sítě. Není ale optimální za všech okolností (například vysoce interaktivní prostředí). Algoritmus Nagle má negativní dopad na výkon požadavků na Azure Table Storage a pokud je to možné, měli byste ho zakázat.

Velikost zprávy

Zvýšení výkonu fronty a škálovatelnosti při nárůstu velikosti zpráv Vložte do zprávy jenom informace, které příjemce potřebuje.

Dávkové načítání

V jedné operaci můžete načíst až 32 zpráv z fronty. Dávkové načítání může snížit počet odezvy z klientské aplikace, což je zvlášť užitečné pro prostředí, jako jsou mobilní zařízení, s vysokou latencí.

Interval dotazování fronty

Většina aplikací se dotazuje na zprávy z fronty, což může být jeden z největších zdrojů transakcí pro danou aplikaci. Vyberte interval dotazování moudře: Příliš časté dotazování může způsobit, že vaše aplikace bude přistupovat k cílům škálovatelnosti fronty. Při 200 000 transakcích za 0,01 USD (v době psaní) by ale jedno dotazování procesoru za měsíc stálo méně než 15 centů, takže náklady obvykle nejsou faktorem, který ovlivňuje váš výběr intervalu dotazování.

Aktuální informace o nákladech najdete v cenách služby Azure Storage.

Provedení operace aktualizace zprávy

Můžete provést operaci aktualizace zprávy, která zvýší časový limit nepřístupnosti nebo aktualizuje informace o stavu zprávy. Tento přístup může být efektivnější než pracovní postup, který předává úlohu z jedné fronty do další, protože každý krok úlohy je dokončený. Aplikace může uložit stav úlohy do zprávy a pokračovat v práci, místo aby zprávu znovu uložila do fronty pro další krok úlohy při každém dokončení kroku. Mějte na paměti, že každá operace aktualizace zpráv se počítá do cíle škálovatelnosti.

Architektura aplikace

Využijte fronty k zajištění škálovatelnosti architektury aplikace. Následující seznam uvádí několik způsobů, jak pomocí front zajistit větší škálovatelnost aplikace:

• Fronty můžete použít k vytvoření backlogů práce pro zpracování a vyhlazování úloh ve vaší aplikaci. Můžete například zařadit žádosti od uživatelů, aby prováděli náročné práce na procesoru, jako je změna velikosti nahraných obrázků.
• Fronty můžete použít k oddělení částí aplikace, abyste je mohli škálovat nezávisle. Webový front-end může například umístit výsledky průzkumu od uživatelů do fronty pro pozdější analýzu a úložiště. Podle potřeby můžete přidat další instance rolí pracovního procesu pro zpracování dat fronty.

Další kroky

• Škálovatelnost a cíle výkonu pro Queue Storage
• Škálovatelnost a výkonnostní cíle pro účty úložiště úrovně Standard
• Kódy stavu a chyb