Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A néha válaszidőként hivatkozott késés az az idő, amelyre az alkalmazásnak várnia kell a kérés befejezéséig. A késés közvetlenül befolyásolhatja az alkalmazás teljesítményét. Az alacsony késleltetés gyakran fontos az olyan helyzetekben, amikor emberek is részt vesznek a folyamatban, mint például hitelkártyás tranzakciók végrehajtása vagy weblapok betöltése során. 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 bemutatja, hogyan értelmezheti és mérheti a blokkblobok műveleteinek 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 a nagy teljesítményű SSD-lemezeken keresztül. További információ: Prémium szintű blokkblobtároló-fiókok.
Tudnivalók az Azure Storage késéséről
Az Azure Storage késése az Azure Storage-műveletek kérési díjával kapcsolatos. 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ének időtartamát, majd számítsa ki, hogy másodpercenként hány kérelem dolgozható fel. Tegyük fel például, hogy egy kérés végrehajtása 50 ezredmásodpercet (ms) vesz igénybe. Egy egy szálat használó alkalmazásnak 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álszám megduplázódik kettőre, 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ési sebesség nem mindig nő lineárisan, mivel az ügyfél által tapasztalt többletterhelés a feladatütemezés, a kontextusváltás és így tovább miatt jelentkezik. A szolgáltatás oldalán az Azure Storage-rendszerre nehezedő nyomás, a használt tárolási adathordozók eltérései, a többi számítási feladat zaja, a karbantartási feladatok és egyéb tényezők miatt a késés ingadozhat. 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 átviteli sebességet eredményez, másodpercenként 40 960 KiB vagy 40 MiB másodpercenként.
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 az Azure Portalon 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 az ügyfél nyugtázását nem kapja meg 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ő csomagja vissza nem érkezik az Azure Storage-ból.
Az alábbi képen az átlagos sikeres E2E késés és átlagos sikeres szerver késés látható a Get Blob műveletet meghívó mintamunkaterhelés 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, ezt mutatja a minta számítási feladat képe.
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 meghaladja a kiszolgáló késését, 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 a hálózaton keresztül továbbított és az Azure Storage által feldolgozott adatok mennyisége miatt.
Az alábbi ábra a különböző méretű műveletek teljes idejét mutatja be. Kis mennyiségű adat esetén a késési időköz elsősorban a kérés kezelésére, nem pedig az adatok átvitelére kerül. 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 jelöléssel). Ahogy a művelet mérete tovább nő, több időt töltenek 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 jelöléssel). 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öl).
Az ügyfélkonfigurációs tényezők, például az egyidejűség és a szálkezelés szintén befolyásolják a késést. Az általános átviteli sebesség attól függ, hogy hány tárolási kérés fut 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ároló é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 cpu- és memóriaerőforrásokra van szükség. Ha az ügyfél nyomás alatt áll egy kevés erőforrással rendelkező virtuális gép vagy a rendszer valamilyen 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övelése nélkül, ami növeli a két metrika közötti különbséget.
Ugyanilyen fontos az ügyfél és az Azure Storage közötti hálózati adapter és hálózati cső. A fizikai távolság önmagában 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 állapota befolyásolhatja a teljes tárolási késést.
A késés felméréséhez először hozzon létre alapmetrikát a forgatókönyvhöz. Az alapvető metrikák az alkalmazási környezetnek megfelelően nyújtanak elvárásokat a teljes folyamatra és a kiszolgáló késleltetésére vonatkozóan, a terhelési profiltól, az alkalmazáskonfigurációs beállításoktól, az ügyfélerőforrásoktól, a hálózati kapcsolattól és egyéb tényezőktől függően. Ha alapmetrikái vannak, 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.