A Queue Storage teljesítmény- és méretezhetőségi ellenőrzőlistája
A Microsoft számos bevált eljárást fejlesztett ki a Queue Storage használatával nagy teljesítményű alkalmazások fejlesztéséhez. Ez az ellenőrzőlista a fejlesztők által a teljesítmény optimalizálásához követhető főbb eljárásokat azonosítja. Tartsa szem előtt ezeket a gyakorlatokat az alkalmazás tervezésekor és a folyamat során.
Az Azure Storage méretezhetőségi és teljesítménycélokkal rendelkezik a kapacitás, a tranzakciós sebesség és a sávszélesség tekintetében. További információ az Azure Storage méretezhetőségi céljairól: Standard tárfiókok méretezhetőségi és teljesítménycéljai, valamint a Queue Storage méretezhetőségi és teljesítménycéljai.
Checklist
Ez a cikk egy olyan ellenőrzőlistába rendezi a teljesítmény bevált eljárásait, amelyek a Queue Storage-alkalmazás fejlesztése során követhetők.
Méretezhetőségi célok
Ha az alkalmazás megközelíti vagy túllépi a méretezhetőségi célok bármelyikét, előfordulhat, hogy a tranzakció késése vagy szabályozása megnő. Amikor az Azure Storage szabályozza az alkalmazást, a szolgáltatás 503 (Server Busy) vagy 500 (Operation Timeout) hibakódot ad vissza. Ezeknek a hibáknak a skálázhatósági célok korlátain belüli elkerülése fontos része az alkalmazás teljesítményének növelésének.
A Queue Storage skálázhatósági céljairól további információt az Azure Storage méretezhetőségi és teljesítménycéljaiban talál.
Tárfiókok maximális száma
Ha egy adott előfizetés/régió kombinációhoz engedélyezett tárfiókok maximális számát közelíti meg, akkor több tárfiókot használ szegmensekre a bejövő, kimenő, I/O-műveletek másodpercenkénti (IOPS) vagy kapacitás növeléséhez? Ebben a forgatókönyvben a Microsoft azt javasolja, hogy használja ki a tárfiókok megnövekedett korlátait, hogy lehetőség szerint csökkentse a számítási feladathoz szükséges tárfiókok számát. Lépjen kapcsolatba az Azure ügyfélszolgálatával , és kérje a tárfiókra vonatkozó megnövekedett korlátokat.
Kapacitás- és tranzakciós célok
Ha az alkalmazás egy tárfiók méretezhetőségi céljaihoz közelít, fontolja meg az alábbi módszerek egyikének alkalmazását:
- Ha az üzenetsorok méretezhetőségi céljai nem elegendőek az alkalmazás számára, használjon több üzenetsort, és ossza el közöttük az üzeneteket.
- Gondolja át azt a számítási feladatot, amely miatt az alkalmazás megközelíti vagy túllépi a méretezhetőségi célt. Meg tudja másképp tervezni, hogy kevesebb sávszélességet vagy kapacitást használjon, vagy kevesebb tranzakciót használjon?
- Ha az alkalmazásnak meg kell haladnia az egyik méretezhetőségi célt, hozzon létre több tárfiókot, és particionálja az alkalmazás adatait a több tárfiók között. Ha ezt a mintát használja, ügyeljen arra, hogy az alkalmazást úgy tervezzen meg, hogy a jövőben további tárfiókokat lehessen hozzáadni a terheléselosztáshoz. Maguk a tárfiókok a tárolt adatok, a tranzakciók vagy az átvitt adatok használatán kívül más költségekkel sem járnak.
- Ha az alkalmazás megközelíti a sávszélesség-célokat, fontolja meg az adatok ügyféloldali tömörítését az adatok Azure Storage-ba való küldéséhez szükséges sávszélesség csökkentése érdekében. Bár az adatok tömörítése sávszélességet takaríthat meg, és javíthatja a hálózati teljesítményt, negatív hatással lehet a teljesítményre is. Értékelje ki az ügyféloldali adattömörítésre és dekompresszióra vonatkozó további feldolgozási követelmények teljesítményre gyakorolt hatását. Ne feledje, hogy a tömörített adatok tárolása megnehezítheti a hibaelhárítást, mivel a standard eszközökkel nehezebb lehet megtekinteni az adatokat.
- Ha az alkalmazás megközelíti a méretezhetőségi célokat, győződjön meg arról, hogy exponenciális visszalépést használ az újrapróbálkozáshoz. A legjobb, ha megpróbálja elkerülni a méretezhetőségi célok elérését a cikkben ismertetett javaslatok végrehajtásával. Ha azonban exponenciális visszalépést használ az újrapróbálkozáshoz, azzal megakadályozza, hogy az alkalmazás gyorsan újrapróbálkozjon, ami ronthat a szabályozáson. További információ: Időtúllépési és kiszolgálói foglaltsági hibák szakasz.
Networking
Az alkalmazás fizikai hálózati korlátai jelentős hatással lehetnek a teljesítményre. Az alábbi szakaszok néhány olyan korlátozást ismertetnek, amelyekkel a felhasználók találkozhatnak.
Ügyfélhálózati képesség
A sávszélesség és a hálózati kapcsolat minősége fontos szerepet játszik az alkalmazások teljesítményében, az alábbi szakaszokban leírtak szerint.
Átviteli sebesség
A sávszélesség esetében a probléma gyakran az ügyfél képességei. A nagyobb Azure-példányok nagyobb kapacitású hálózati adapterekkel rendelkeznek, ezért érdemes megfontolni egy nagyobb példány vagy több virtuális gép használatát, ha nagyobb hálózati korlátokra van szüksége egyetlen gépről. Ha helyszíni alkalmazásból éri el az Azure Storage-t, ugyanez a szabály érvényes: ismerje meg az ügyféleszköz hálózati képességeit és az Azure Storage helyéhez való hálózati kapcsolatot, és szükség szerint javítsa őket, vagy tervezze meg az alkalmazást, hogy a képességeiknek megfelelően működjön.
Kapcsolat minősége
A hálózati használathoz hasonlóan ne feledje, hogy a hibákat és csomagvesztést eredményező hálózati feltételek lassítják a hatékony átviteli sebességet. A Wireshark vagy a Network Monitor használata segíthet a probléma diagnosztizálásában.
Location
Bármely elosztott környezetben az ügyfél kiszolgálóhoz közeli elhelyezése a legjobb teljesítményt nyújtja. A legalacsonyabb késéssel rendelkező Azure Storage eléréséhez az ügyfél számára a legjobb hely ugyanabban az Azure-régióban található. Ha például van egy Azure-webalkalmazása, amely az Azure Storage-t használja, akkor mindkettőt egyetlen régióban, például az USA nyugati régiójában vagy Délkelet-Ázsiában találja. Az erőforrások közös keresése csökkenti a késést és a költségeket, mivel az egyetlen régión belüli sávszélesség-használat ingyenes.
Ha az ügyfélalkalmazások hozzáférnek az Azure Storage-hoz, de nem az Azure-ban vannak üzemeltetve, például mobileszköz-alkalmazásokat vagy helyszíni vállalati szolgáltatásokat, akkor a tárfióknak az ügyfelekhez közeli régióban való keresése csökkentheti a késést. Ha az ügyfelek széles körben vannak elosztva (például néhány Észak-Amerika és néhány Európában), akkor érdemes lehet régiónként egy tárfiókot használni. Ez a megközelítés könnyebben implementálható, ha az alkalmazás által tárolt adatok egyedi felhasználókra vonatkoznak, és nem igényelnek adatok replikálását a tárfiókok között.
SAS és CORS
Tegyük fel, hogy engedélyeznie kell a felhasználó webböngészőjében vagy egy mobiltelefonos alkalmazásban futó kódokat, például a JavaScriptet az Azure Storage-adatok eléréséhez. Az egyik módszer egy proxyként működő szolgáltatásalkalmazás létrehozása. A felhasználó eszköze a szolgáltatással hitelesít, ami viszont engedélyezi az Azure Storage-erőforrásokhoz való hozzáférést. Ily módon elkerülheti a tárfiókkulcsok nem biztonságos eszközökön való felfedését. Ez a megközelítés azonban jelentős többletterhelést jelent a szolgáltatásalkalmazáson, mivel a felhasználó eszköze és az Azure Storage között átvitt összes adatnak át kell haladnia a szolgáltatásalkalmazáson.
Elkerülheti, hogy egy szolgáltatásalkalmazást proxyként használjon az Azure Storage-hoz közös hozzáférésű jogosultságkódok (SAS) használatával. Az SAS használatával engedélyezheti, hogy a felhasználó eszköze egy korlátozott hozzáférési jogkivonat használatával közvetlenül az Azure Storage-ba küldjön kéréseket. Ha például egy felhasználó fel szeretne tölteni egy fényképet az alkalmazásba, akkor a szolgáltatásalkalmazás létrehozhat egy SAS-t, és elküldheti azt a felhasználó eszközére. Az SAS-jogkivonat engedélyt adhat egy Azure Storage-erőforrásba való írásra egy megadott ideig, amely után az SAS-jogkivonat lejár. További információ az SAS-ről: Korlátozott hozzáférés biztosítása az Azure Storage-erőforrásokhoz közös hozzáférésű jogosultságkódok (SAS) használatával.
A webböngészők általában nem engedélyezik a JavaScript használatát az egyik tartomány webhelye által üzemeltetett lapon bizonyos műveletek, például írási műveletek egy másik tartományba történő végrehajtásához. Az azonos eredetű szabályzatként ismert házirend megakadályozza, hogy egy rosszindulatú szkript egy oldalon hozzáférjen egy másik weblap adataihoz. Az azonos eredetű szabályzat azonban korlátozhatja a felhőben történő megoldáskészítést. A forrásközi erőforrás-megosztás (CORS) egy böngészőfunkció, amely lehetővé teszi a céltartomány számára, hogy a forrástartományból származó kéréseket megbízhatónak minősítő böngészővel kommunikáljon.
Tegyük fel például, hogy egy Azure-ban futó webalkalmazás egy Azure Storage-fiókba küld egy erőforrást. A webalkalmazás a forrástartomány, a tárfiók pedig a céltartomány. Bármelyik Azure Storage-szolgáltatáshoz konfigurálhatja a CORS-t, hogy a forrástartományból érkező kéréseket az Azure Storage megbízhatónak minősítő webböngészővel kommunikáljon. A CORS-ról további információt az Azure Storage forrásközi erőforrás-megosztási (CORS) támogatásában talál.
Az SAS és a CORS segítségével elkerülheti a webalkalmazás felesleges terhelését.
.NET-konfiguráció
A .NET-keretrendszer használó projektek esetében ez a szakasz felsorol néhány gyors konfigurációs beállítást, amelyekkel jelentős teljesítménybeli javulást érhet el. Ha nem .NET-nyelvet használ, ellenőrizze, hogy a választott nyelven vannak-e hasonló fogalmak.
Az alapértelmezett kapcsolatkorlát növelése
Megjegyzés:
Ez a szakasz a .NET-keretrendszer használó projektekre vonatkozik, mivel a kapcsolatkészletezést a ServicePointManager osztály vezérli. A .NET Core jelentős változást vezetett be a kapcsolatkészlet kezelése körül, ahol a kapcsolatkészletezés a HttpClient szintjén történik, és a készlet mérete alapértelmezés szerint nem korlátozott. Ez azt jelenti, hogy a HTTP-kapcsolatok automatikusan skálázódnak a számítási feladatok kielégítése érdekében. A .NET legújabb verziójának használata ajánlott, ha lehetséges, a teljesítménybeli fejlesztések előnyeinek kihasználásához.
Az .NET-keretrendszer használó projektek esetében az alábbi kóddal növelheti az alapértelmezett kapcsolati korlátot (amely ügyfélkörnyezetben általában 2, kiszolgálói környezetben 10) 100-ra. Az értéket általában körülbelül az alkalmazás által használt szálak számának megfelelő értékre kell állítania. A kapcsolatok megnyitása előtt állítsa be a kapcsolatkorlátot.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
A .NET-keretrendszer kapcsolatkészletkorlátairól további információt a .NET-keretrendszer Csatlakozás ion Pool Limits és az új Azure SDK for .NET című témakörben talál.
Más programozási nyelvek esetén a dokumentációból megtudhatja, hogyan állíthatja be a kapcsolati korlátot.
Szálak minimális számának növelése
Ha szinkron hívásokat és aszinkron feladatokat használ, érdemes lehet növelni a szálak számát a szálkészletben:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
További információ: ThreadPool.SetMinThreads metódus.
Kötetlen párhuzamosság
Bár a párhuzamosság kiválóan alkalmas a teljesítményre, ügyeljen a kötetlen párhuzamosság használatára, ami azt jelenti, hogy nincs korlátozva a szálak vagy párhuzamos kérések száma. Ügyeljen arra, hogy korlátozza az adatok feltöltésére vagy letöltésére irányuló párhuzamos kérelmeket, hogy ugyanabban a tárfiókban több partícióhoz férhessen hozzá, vagy hogy ugyanabban a partícióban több elemhez is hozzáférhessen. Ha a párhuzamosság nem kötött, az alkalmazás túllépheti az ügyféleszköz képességeit vagy a tárfiók méretezhetőségi céljait, ami hosszabb késéseket és szabályozást eredményez.
Ügyfélkódtárak és -eszközök
A legjobb teljesítmény érdekében mindig a Microsoft által biztosított legújabb ügyfélkódtárakat és eszközöket használja. Az Azure Storage-ügyfélkódtárak különböző nyelvekhez érhetők el. Az Azure Storage a PowerShellt és az Azure CLI-t is támogatja. A Microsoft aktívan fejleszti ezeket az ügyfélkódtárakat és eszközöket a teljesítmény szem előtt tartásával, naprakészen tartja őket a legújabb szolgáltatásverziókkal, és biztosítja, hogy belsőleg kezelje a bevált teljesítménybeli eljárások nagy részét. További információkért tekintse meg az Azure Storage referenciadokumentációját.
Szolgáltatáshibák kezelése
Az Azure Storage hibát ad vissza, ha a szolgáltatás nem tud feldolgozni egy kérést. Az Azure Storage által adott forgatókönyvben visszaadott hibák megértése hasznos a teljesítmény optimalizálásához.
Időtúllépési és kiszolgálói foglaltsági hibák
Az Azure Storage korlátozhatja az alkalmazást, ha megközelíti a méretezhetőség korlátait. Bizonyos esetekben előfordulhat, hogy az Azure Storage valamilyen átmeneti feltétel miatt nem tudja kezelni a kéréseket. Mindkét esetben előfordulhat, hogy a szolgáltatás 503 (Server Busy) vagy 500 (Timeout) hibát ad vissza. Ezek a hibák akkor is előfordulhatnak, ha a szolgáltatás újraegyensúlyozza az adatpartíciókat a nagyobb átviteli sebesség érdekében. Az ügyfélalkalmazásnak általában újra kell próbálkoznia az ilyen hibákat okozó művelettel. Ha azonban az Azure Storage azért szabályozza az alkalmazást, mert túllépi a méretezhetőségi célokat, vagy ha a szolgáltatás valamilyen más okból nem tudta kiszolgálni a kérést, az agresszív újrapróbálkozások tovább ronthatják a problémát. Az exponenciális visszatartási újrapróbálkozási szabályzat használata ajánlott, és az ügyfélkódtárak alapértelmezés szerint ezt a viselkedést használják. Előfordulhat például, hogy az alkalmazás 2 másodperc, majd 4 másodperc, 10 másodperc, majd 30 másodperc után újra próbálkozik, majd teljesen feladja. Ily módon az alkalmazás jelentősen csökkenti a szolgáltatás terhelését ahelyett, hogy fokozná a szabályozáshoz vezető viselkedést.
Csatlakozás tivitási hibák azonnal újrapróbálhatók, mert nem a szabályozás eredménye, és várhatóan átmenetiek lesznek.
Nem újrapróbálkozható hibák
Az ügyfélkódtárak kezelik az újrapróbálkozásokat, és tisztában vannak azzal, hogy mely hibák próbálkozhatók újra, és melyek nem. Ha azonban közvetlenül az Azure Storage REST API-t hívja meg, vannak olyan hibák, amelyeket nem szabad újrapróbálkoznia. Egy 400 -os (Bad Request) hiba például azt jelzi, hogy az ügyfélalkalmazás olyan kérelmet küldött, amely nem dolgozható fel, mert nem volt a várt formában. A kérés újraküldése minden alkalommal ugyanazt a választ eredményezi, így nincs értelme újrapróbálkozni. Ha közvetlenül az Azure Storage REST API-t hívja meg, vegye figyelembe a lehetséges hibákat, és hogy újra kell-e próbálkoznia.
Az Azure Storage hibakódjaival kapcsolatos további információkért tekintse meg az Állapot és a hibakódok című témakört.
A Nagle algoritmusának letiltása
A Nagle algoritmusa széles körben implementálva van a TCP/IP-hálózatokon a hálózati teljesítmény javítása érdekében. Ez azonban nem optimális minden körülmények között (például rendkívül interaktív környezetekben). A Nagle algoritmusa negatív hatással van az Azure Table Storage-ra irányuló kérések teljesítményére, és ha lehetséges, tiltsa le.
Üzenet mérete
Az üzenetsorok teljesítménye és méretezhetősége az üzenet méretének növekedésével csökken. Csak azokat az információkat helyezze el egy üzenetben, amelyekre a fogadónak szüksége van.
Kötegelt lekérés
Egyetlen műveletben akár 32 üzenetet is lekérhet egy üzenetsorból. A kötegelt lekérés csökkentheti az ügyfélalkalmazásból érkező oda-vissza utak számát, ami különösen hasznos a nagy késésű környezetekben, például mobileszközökön.
Üzenetsor lekérdezési időköze
A legtöbb alkalmazás egy üzenetsor üzeneteit kérdezi le, amely az alkalmazás egyik legnagyobb tranzakcióforrása lehet. Válassza ki a lekérdezési időközt okosan: a túl gyakori lekérdezés miatt az alkalmazás megközelítheti az üzenetsor méretezhetőségi céljait. Azonban 200 000 $0,01 tranzakciónál (az írás időpontjában) egyetlen processzor lekérdezése másodpercenként egy hónapra kevesebb, mint 15 centbe kerül, így a költségek általában nem olyan tényezők, amelyek befolyásolják a lekérdezési időköz kiválasztását.
A legfrissebb költséginformációkért tekintse meg az Azure Storage díjszabását.
Frissítési üzenet művelet végrehajtása
Az üzenetfrissítési művelettel növelheti a láthatatlanság időtúllépését, vagy frissítheti az üzenet állapotadatait. Ez a megközelítés hatékonyabb lehet, mint egy olyan munkafolyamat, amely az egyik üzenetsorból a másikba továbbítja a feladatokat, mivel a feladat minden lépése befejeződött. Az alkalmazás mentheti a feladat állapotát az üzenetbe, majd folytathatja a munkát, ahelyett, hogy a feladat következő lépéséhez tartozó üzenetet minden egyes lépés befejezésekor újra lekérdezi. Ne feledje, hogy minden frissítési üzenet művelete beleszámít a méretezhetőségi célba.
Alkalmazásarchitektúra
Üzenetsorok használatával skálázhatóvá teheti az alkalmazásarchitektúrát. Az alábbiakban felsorolunk néhány módszert, amelyekkel az üzenetsorok használatával skálázhatóbbá teheti az alkalmazást:
- Az üzenetsorokkal munkanaplókat hozhat létre az alkalmazás számítási feladatainak feldolgozásához és kisimításához. Például várólistára állíthatja a felhasználóktól érkező kéréseket a processzorigényes munka, például a feltöltött képek átméretezése érdekében.
- Az üzenetsorokkal leválaszthatja az alkalmazás egyes részeit, így egymástól függetlenül skálázhatja őket. Egy webes előtér például egy üzenetsorba helyezheti a felhasználók felmérési eredményeit későbbi elemzés és tárolás céljából. Szükség szerint további feldolgozói szerepkörpéldányokat is hozzáadhat az üzenetsor adatainak feldolgozásához.