Latence v úložišti objektů blob

Latence, která se někdy označuje jako doba odezvy, je doba, po kterou musí aplikace čekat na dokončení požadavku. Latence může přímo ovlivnit výkon aplikace. Nízká latence je často důležitá pro scénáře s lidmi ve smyčce, jako je provádění transakcí pomocí platebních karet nebo načítání webových stránek. Systémy, které potřebují zpracovávat příchozí události vysokou rychlostí, jako je protokolování telemetrie nebo události IoT, také vyžadují nízkou latenci. Tento článek popisuje, jak porozumět a měřit latenci operací s objekty blob bloku a jak navrhnout aplikace s nízkou latencí.

Azure Storage nabízí dvě různé možnosti výkonu pro objekty blob bloku: Premium a Standard. Objekty blob bloku úrovně Premium nabízejí výrazně nižší a konzistentnější latenci než objekty blob bloku úrovně Standard prostřednictvím vysoce výkonných disků SSD. Další informace najdete v tématu Úložiště objektů blob bloku výkonu úrovně Premium v horké, studené a archivní úrovni přístupu k datům objektů blob.

Informace o latenci služby Azure Storage

Latence služby Azure Storage souvisí s sazbami požadavků na operace azure Storage. Frekvence požadavků se také označují jako vstupně-výstupní operace za sekundu (IOPS).

Pokud chcete vypočítat rychlost požadavků, nejprve určete dobu, po kterou každý požadavek trvá, a pak vypočítejte, kolik požadavků lze zpracovat za sekundu. Předpokládejme například, že dokončení požadavku trvá 50 milisekund (ms). Aplikace používající jedno vlákno s jednou nevyřízenou operací čtení nebo zápisu by měla dosáhnout 20 IOPS (1 sekunda nebo 1 000 ms / 50 ms na požadavek). Teoreticky platí, že pokud se počet vláken zdvojnásobí na dvě, aplikace by měla být schopná dosáhnout 40 IOPS. Pokud se nevyřízené asynchronní operace čtení nebo zápisu pro každé vlákno zdvojnásobí na dvě, aplikace by měla být schopna dosáhnout 80 IOPS.

V praxi se frekvence požadavků ne vždy škálují lineárně, a to kvůli režii v klientovi z plánování úkolů, přepínání kontextu atd. Na straně služby může docházet k proměnlivosti latence kvůli tlaku na systém Azure Storage, rozdílům v používaných úložných médiích, šumu z jiných úloh, úlohám údržby a dalším faktorům. Síťové připojení mezi klientem a serverem může mít vliv na latenci služby Azure Storage kvůli zahlcení, přesměrování nebo jiným přerušením.

Šířka pásma služby Azure Storage, označovaná také jako propustnost, souvisí s četností požadavků a dá se vypočítat vynásobením frekvence požadavků (IOPS) velikostí požadavku. Například při 160 žádostech za sekundu má každý 256 KiB dat propustnost 40 960 KiB za sekundu nebo 40 MiB za sekundu.

Metriky latence pro objekty blob bloku

Azure Storage poskytuje dvě metriky latence pro objekty blob bloku. Tyto metriky můžete zobrazit v Azure Portal:

• Latence E2E (End-to-End) měří interval od přijetí prvního paketu požadavku službou Azure Storage do doby, než Azure Storage obdrží potvrzení klienta u posledního paketu odpovědi.

• Latence serveru měří interval od přijetí posledního paketu požadavku službou Azure Storage do vrácení prvního paketu odpovědi ze služby Azure Storage.

Následující obrázek znázorňuje latenci average success E2E a Average Success Server Latency pro ukázkovou úlohu, která volá Get Blob operaci:

Za normálních podmínek existuje malá mezera mezi latencí od konce do konce a latencí serveru, což je to, co obrázek ukazuje pro ukázkovou úlohu.

Pokud zkontrolujete metriky latence mezi koncovými body a metrikami latence serveru a zjistíte, že latence mezi koncovými body je výrazně vyšší než latence serveru, prozkoumejte a vyřešte zdroj další latence.

Pokud je latence serveru a koncového bodu podobná, ale potřebujete nižší latenci, zvažte migraci na úložiště objektů blob bloku úrovně Premium.

Faktory ovlivňující latenci

Hlavním faktorem ovlivňujícím latenci je velikost operace. Dokončení rozsáhlejších operací trvá déle kvůli množství dat přenášených přes síť a zpracovávaných službou Azure Storage.

Následující diagram znázorňuje celkovou dobu operací různých velikostí. U malých objemů dat se interval latence převážně věnuje zpracování požadavku, nikoli přenosu dat. Interval latence se s rostoucí velikostí operace jen mírně zvyšuje (v následujícím diagramu je označeno 1). S tím, jak se velikost operace dále zvětšuje, se přenosem dat věnuje více času, takže celkový interval latence se rozdělí mezi zpracování požadavků a přenos dat (v následujícím diagramu je označený 2). Při větších velikostech operací se interval latence téměř výhradně věnuje přenosu dat a zpracování požadavků je do značné míry nevýznamné (v následujícím diagramu je označeno 3).

Na latenci mají vliv také faktory konfigurace klienta, jako je souběžnost a dělení vláken. Celková propustnost závisí na tom, kolik požadavků na úložiště je v daném okamžiku ve fázi a jak vaše aplikace zpracovává vlákna. Latenci můžou ovlivnit také prostředky klienta, včetně procesoru, paměti, místního úložiště a síťových rozhraní.

Zpracování požadavků služby Azure Storage vyžaduje prostředky procesoru a paměti klienta. Pokud je klient pod tlakem kvůli nedostatečně silnému virtuálnímu počítači nebo nějakému neběžnýmu procesu v systému, je k dispozici méně prostředků pro zpracování požadavků služby Azure Storage. Jakékoli kolize nebo nedostatek prostředků klienta způsobí zvýšení celkové latence bez zvýšení latence serveru, což zvětší mezeru mezi dvěma metrikami.

Stejně důležité je síťové rozhraní a síťový kanál mezi klientem a službou Azure Storage. Samotná fyzická vzdálenost může být významným faktorem, například pokud se klientský virtuální počítač nachází v jiné oblasti Azure nebo v místním prostředí. Další faktory, jako jsou směrování sítě, směrování poskytovatele internetových služeb a stav internetu, můžou ovlivnit celkovou latenci úložiště.

Pokud chcete vyhodnotit latenci, nejprve vytvořte základní metriky pro váš scénář. Metriky podle směrného plánu poskytují očekávanou latenci serveru a koncového serveru v kontextu prostředí vaší aplikace v závislosti na profilu úloh, nastavení konfigurace aplikace, prostředcích klienta, síťovém kanálu a dalších faktorech. Pokud máte základní metriky, můžete snadněji identifikovat abnormální a normální podmínky. Metriky směrného plánu také umožňují sledovat účinky změněných parametrů, jako je konfigurace aplikací nebo velikosti virtuálních počítačů.

Další kroky

• Škálovatelnost a cíle výkonu pro úložiště objektů blob
• Kontrolní seznam k výkonu a škálovatelnosti pro službu Blob Storage