Késés a Blob Storage-ban

A késés , amelyre néha válaszidőként hivatkoznak, az az idő, ameddig az alkalmazásnak várnia kell a kérés befejezésére. A késés közvetlenül befolyásolhatja az alkalmazás teljesítményét. Az alacsony késés gyakran fontos az olyan helyzetekben, amikor az emberek a hurokba kerülnek, például hitelkártya-tranzakciókat hajtanak végre vagy weblapokat töltenek be. Azok a rendszerek, amelyeknek nagy sebességgel kell feldolgozni a bejövő eseményeket, például a telemetriai naplózást vagy az IoT-eseményeket, szintén alacsony késést igényelnek. Ez a cikk azt ismerteti, hogyan értelmezheti és mérheti a blokkblobokon végzett műveletek késését, és hogyan tervezheti meg az alkalmazásokat alacsony késésre.

Az Azure Storage két különböző teljesítménylehetőséget kínál a blokkblobokhoz: prémium és standard. A prémium szintű blokkblobok jelentősen alacsonyabb és konzisztensebb késést kínálnak, mint a standard blokkblobok nagy teljesítményű SSD-lemezekkel. További információ: Prémium szintű teljesítményblokkblobtárolók a blobadatokgyakori elérésű, ritka elérésű és archív hozzáférési szintjeiben.

Tudnivalók az Azure Storage késéséről

Az Azure Storage késése az Azure Storage-műveletek kérési sebességéhez kapcsolódik. A kérések sebességét másodpercenkénti bemeneti/kimeneti műveleteknek (IOPS) is nevezik.

A kérelem sebességének kiszámításához először határozza meg az egyes kérések befejezéséhez szükséges időtartamot, majd számítsa ki, hogy hány kérelem dolgozható fel másodpercenként. Tegyük fel például, hogy egy kérés végrehajtása 50 ezredmásodpercet (ms) vesz igénybe. Egy olyan alkalmazásnak, amely egy szálat használ egy kiemelkedő olvasási vagy írási művelettel, 20 IOPS-t kell elérnie (kérésenként 1 másodperc vagy 1000 ms / 50 ms). Elméletileg, ha a szálak száma kettőre nő, akkor az alkalmazásnak 40 IOPS-t kell elérnie. Ha az egyes szálakhoz tartozó aszinkron olvasási vagy írási műveletek duplájára vannak állítva, akkor az alkalmazásnak 80 IOPS-t kell elérnie.

A gyakorlatban a kérések aránya nem mindig skálázható olyan lineárisan, mivel az ügyfél többletterhelést okoz a feladatütemezésből, a környezetváltásból és így tovább. A szolgáltatás oldalán a késés ingadozhat az Azure Storage rendszerre gyakorolt nyomás, a felhasznált tároló adathordozók eltérései, más számítási feladatok zaja, karbantartási feladatok és egyéb tényezők miatt. Végül az ügyfél és a kiszolgáló közötti hálózati kapcsolat hatással lehet az Azure Storage késésére a torlódás, az átirányítás vagy más fennakadások miatt.

Az Azure Storage sávszélessége, más néven átviteli sebesség, a kérelem sebességéhez kapcsolódik, és a kérelem sebességének (IOPS) és a kérelem méretének szorzatával számítható ki. Ha például másodpercenként 160 kérést feltételezünk, minden 256 KiB adat másodpercenként 40 960 KiB vagy másodpercenként 40 MiB átviteli sebességet eredményez.

A blokkblobok késési metrikái

Az Azure Storage két késési metrikát biztosít a blokkblobokhoz. Ezek a metrikák a Azure Portal tekinthetők meg:

• A végpontok közötti (E2E) késés azt az időtartamot méri, amikor az Azure Storage megkapja a kérés első csomagját, amíg az Azure Storage meg nem kapja az ügyfél nyugtázását a válasz utolsó csomagján.

• A kiszolgáló késése azt az időtartamot méri, amikor az Azure Storage megkapja a kérés utolsó csomagját, amíg a válasz első csomagját vissza nem adja az Azure Storage.

Az alábbi képen az E2E átlagos késése és a sikeres kiszolgáló átlagos késése látható a műveletet meghívó Get Blob minta számítási feladatok esetében:

Normál körülmények között kevés a különbség a végpontok közötti késés és a kiszolgáló késése között, amit a rendszerkép a minta számítási feladathoz mutat.

Ha áttekinti a végpontok közötti és a kiszolgálói késési metrikákat, és úgy találja, hogy a végpontok közötti késés jelentősen nagyobb, mint a kiszolgáló késése, vizsgálja meg és kezelje a további késés forrását.

Ha a végpontok közötti és a kiszolgálói késés hasonló, de alacsonyabb késést igényel, fontolja meg a prémium szintű blokkblobtárolóba való migrálást.

A késést befolyásoló tényezők

A késést befolyásoló fő tényező a művelet mérete. A nagyobb műveletek végrehajtása hosszabb időt vesz igénybe, mivel a hálózaton átvitt és az Azure Storage által feldolgozott adatok mennyisége hosszabb időt vesz igénybe.

Az alábbi ábrán a különböző méretű műveletek teljes időtartama látható. Kis mennyiségű adat esetén a késési időköz elsősorban a kérések kezelésére, nem pedig az adatok átvitelére van fordítva. A késési időköz csak kismértékben nő a művelet méretének növekedésével (az alábbi ábrán 1-et jelölt meg). Ahogy a művelet mérete tovább nő, több időt tölt az adatok átvitelével, így a teljes késési intervallum fel van osztva a kérések kezelése és az adatátvitel között (az alábbi ábrán 2-es jelöléssel van ellátva). Nagyobb műveletméretek esetén a késési időköz szinte kizárólag az adatok átvitelére van fordítva, és a kérések kezelése nagyrészt jelentéktelen (az alábbi ábrán 3-at jelölt meg).

Az ügyfélkonfigurációs tényezők, például az egyidejűség és a szálkezelés szintén hatással vannak a késésre. A teljes átviteli sebesség attól függ, hogy hány tárolási kérelem van folyamatban egy adott időpontban, és hogy az alkalmazás hogyan kezeli a szálkezelést. Az ügyfélerőforrások, például a processzor, a memória, a helyi tárterület és a hálózati adapterek szintén hatással lehetnek a késésre.

Az Azure Storage-kérelmek feldolgozásához ügyfél processzor- és memóriaerőforrásokra van szükség. Ha az ügyfélre nyomás nehezedik egy kevés erőforrással rendelkező virtuális gép vagy a rendszer valamely elszabadult folyamata miatt, kevesebb erőforrás áll rendelkezésre az Azure Storage-kérelmek feldolgozásához. Az ügyfélerőforrások bármilyen versengése vagy hiánya a végpontok közötti késés növekedését eredményezi a kiszolgáló késésének növekedése nélkül, ami növeli a két metrika közötti különbséget.

Ugyanilyen fontos a hálózati adapter és a hálózati cső az ügyfél és az Azure Storage között. A fizikai távolság önmagában is jelentős tényező lehet, például ha egy ügyfél virtuális gép egy másik Azure-régióban vagy a helyszínen található. Más tényezők, például a hálózati ugrások, az internetszolgáltatói útválasztás és az internetállapot befolyásolhatják a teljes tárolási késést.

A késés felméréséhez először hozzon létre alapkonfiguráció-metrikákat a forgatókönyvéhez. Az alapkonfiguráció-metrikák a várt végpontok közötti és kiszolgálói késést biztosítják az alkalmazáskörnyezet kontextusában a számítási feladatprofiltól, az alkalmazáskonfigurációs beállításoktól, az ügyfélerőforrásoktól, a hálózati csőtől és egyéb tényezőktől függően. Ha rendelkezik alapmetrikákkal, könnyebben azonosíthatja a rendellenes és a normál állapotokat. Az alapkonfigurációs metrikák lehetővé teszik a megváltozott paraméterek, például az alkalmazáskonfiguráció vagy a virtuálisgép-méretek hatásainak megfigyelését is.

Következő lépések

• Skálázhatósági és teljesítménycélok a Blob Storage-hoz
• Teljesítménnyel és méretezhetőséggel kapcsolatos ellenőrzőlista a Blob Storage-hoz