Alkalmazásoptimalizálás, alkalmazások skálázása
Következő Az alkalmazás telepítése, írja be működését és ez jól működik az első néhány hét, de a növekedés a felhasználók száma növekszik, és a kérelmek számát fel kell dolgozni, hogy a szerver, és hirtelen, a szerver elkezdi megfojtani. Eleinte ez megnyilvánulhat növekedését lekérdezés feldolgozási idő, akkor a munkafolyamat kezd több memóriával és feldolgozási erőforrásokat, és végső soron a web szerver egyszerűen megszűnik képes feldolgozni az összes kérést és a naplófájlokat egyre inkább HTTP 500 üzenet ( «Internal Server Error» ).
Mi történt? Elkezdhetem újra optimalizálni az alkalmazást? A felhasználók számának növekedésével azonban a helyzet ismétlődik. Növelhetem a memória mennyiségét, vagy hozzáadhatok processzorokat? Azonban az egyetlen számítógép képességeinek ilyen kiterjesztése korlátozott. Ideje felismerni azt a tényt, hogy további szerverekre van szükség.
A webes alkalmazások méretezése természetes folyamat, amely a webes alkalmazások életében valamikor megkezdődik. Egy kiszolgáló egyidejűleg tízet, több száz és akár több ezer felhasználót tud kiszolgálni, de sokáig nem tudja elviselni a csúcsterhelést. Memory kezd töltse ki a session információkat, feldolgozása új kérelmek miatt szünetel, mivel nincs szabad szálak és kontextus váltás végrehajtása túl gyakran, ami növeli a késleltetést és csökkentett sávszélességét.
Vízszintes méretezés
Építészeti szempontból a méretezés egyáltalán nem bonyolult: elegendő egy vagy két másik számítógép (vagy tíz) megvásárlása, a kiszolgálókat a terheléskiegyenlítést végző számítógép mögé helyezni, és ez az! De a probléma az, hogy általában minden nem egyszerű.
A fejlesztők által felvetett vízszintes méretezés egyik fő problémája, hogy hogyan kell végrehajtani a szerverhez való kötést. Például, ha egy webszerver fut, a felhasználói munkamenet állapotáról a memóriában tárolt adatok tárolódnak. Ha hozzáad egy másik szervert, hogyan adhat hozzáférést a munkamenet-objektumokhoz? Hogyan tudom szinkronizálni a munkameneteket a szerverek között?
Néhány webfejlesztő úgy oldja meg ezt a problémát, hogy információkat tárol a kiszolgálón, és az ügyfélt egy adott kiszolgálóhoz társítja. Amint az ügyfél a terheléskiegyenlítő mögött lévő kiszolgálókhoz csatlakozik, attól a pillanattól kezdve az ügyféltől származó összes kérés ugyanarra a webkiszolgálóra kerül. Ezt a technikát egy munkamenet-összerendelésnek is nevezik. A munkamenet-összerendelés egy megoldás, de nem oldja meg a problémát, mert nem teszi lehetővé a terhelés egyenletesen elosztását a kiszolgálók között. Ezzel a technikával egyszerűen bejuthat egy olyan helyzetbe, ahol egy kiszolgáló sok felhasználót szolgál ki, míg mások ebben az időben üresednek, mert ügyfeleik már befejezték a munkájukat, és lekapcsolták őket.
Ezért a valódi megoldás az, hogy ne használja a számítógép memóriáját olyan adatok tárolására, mint a felhasználói munkamenetek vagy gyorsítótárak adatai. De hogyan tárolhatja a gyorsítótárat egy adott számítógép memóriájába?
Képzeljük el, mi fog történni, ha a felhasználó elküld egy kérést, ami miatt a gyorsítótár frissítése: szerver fogadja a kérést, frissíti a cache memóriát, de más szerverek nem fogja tudni, hogy meg kell tenni, és ha a cache tárolt másolata ugyanazt a tárgyat, akkor az adatok következetlenségére az egész alkalmazásban. A probléma megoldásának egyik módja a szerverek közötti gyorsítótár objektumok szinkronizálása. Ez lehetséges, de bonyolítja a webes alkalmazás általános architektúráját, nem beszélve arról, hogy a szerverek közötti forgalom nőni fog.
Méretezési mechanizmusok az ASP.NET-ben
A vízszintes méretezéshez az állapotinformációkat a folyamatokon kívül kell tárolni. Az ASP.NET-ben két mechanizmus létezik, amelyek így adatokat tárolnak:
Állami szolgálat
Az állami menedzsment szolgáltatás olyan Windows szolgáltatás, amely támogatja az állami irányítást több számítógép számára. Ez a szolgáltatás automatikusan települ a .NET-keretrendszer telepítésekor, de alapértelmezés szerint ki van kapcsolva. Csak ki kell választania, hogy melyik szerver fogja futtatni az állami menedzsment szolgáltatást, és konfigurálja az összes többi felhasználását. Bár az állami irányítási szolgáltatás lehetővé teszi több szerver számára, hogy közös információs boltot használjon, nem támogatja a hosszú távú tárolást. Vagyis, ha valami történik a kiszolgálón, ahol ez a szolgáltatás fut, akkor minden adat a webes farmon belüli munkamenetekről elvész.
Az ASP.NET támogatja az állapotinformációk tárolását az SQL Server adatbázisban. Ez a mechanizmus nem csak támogatja az azonos funkciók, mint az állami irányítás szolgáltatás, hanem hosszú távon biztosítja az adatok tárolása, így még ha a webszerver és a szerver SQL Server adatbázis történnek sürgős információkat az állam továbbra is.
Gyorsítótárazási célokra a legtöbb esetben sikeresen használhatja az elosztott gyorsítótár-mechanizmusok egyikét, például a Microsoft AppFabric Cache eszközt. NCache vagy Memcached. az utóbbi pedig az elosztott gyorsítótár nyitott megvalósítása.
Az elosztott gyorsítótárazási mechanizmus lehetővé teszi több kiszolgáló memóriájának egy elosztott gyorsítótárba való egyesítését. Elosztott cache támogatja kivételi helyen, így nem szükséges, hogy tudja, hol minden adat, az értesítési szolgáltatás segítségével mindig naprakész - hol és mit sem változott, és a magas rendelkezésre állás biztosítja, hogy még abban az esetben a baleseti adatok nem vesznek el az egyik a szerverek.
Egyes elosztott gyorsítótárak, mint például az AppFabric Cache és a Memcached, szintén rendelkeznek saját állapotkezelési szolgáltatási implementációkkal és cache-szolgáltatókkal az ASP.NET-hez.
Vízszintes skálázó csapdák
Bár ez nem közvetlenül kapcsolódik a teljesítményhez, érdemes azonosítani azokat a problémákat, amelyekkel találkozhat webes alkalmazások méretezésével kapcsolatban.
A webes alkalmazások egyes részei különleges biztonsági kulcsok használatát igénylik egyedi azonosítók létrehozása érdekében, amelyek megakadályozzák a megtévesztő webes alkalmazás és behatolás lehetőségét. Például egy egyedi kulcsot használnak a FormsAuthentication hitelesítési eljárásában, és amikor az adatokat a megtekintési állapot tartós mechanizmusa titkosítja. Alapértelmezés szerint a webalkalmazások biztonsági kulcsai generálódnak minden alkalommal, amikor az alkalmazáskészlet indítása megtörtént.
Egy szerver esetén ez nem okoz problémát, de ha a webes alkalmazás több szerveren fut, akkor ez problémává válhat, mivel minden kiszolgálónak saját egyedi kulcsa lesz. Képzeld el ezt a helyzetet: a kliens küld egy kérést a szerver egy és fogadja a cookie válaszként által aláírt egyedi kulcsot a szerver részére, akkor a kliens küld egy új kérelmet a kapott sütit, amely megkapja a szerver B. Mivel a B szerver egyedi kulccsal, a tartalmát a cookie érvénytelennek minősül, és az ügyfél hibaüzenet jelenik meg.
Ezeket a kulcsokat az ASP.NET-ben állíthatja be, konfigurálva a beállításokat a machineKey szakaszban, a web.config fájlban. Ha egy webes alkalmazás több szerveren fut, akkor meg kell adnia az összes kiszolgálót, hogy ugyanazt az előre létrehozott kulcsot használja.
Egy másik probléma a vízszintes skálázással és egyedi billentyűkkel a partíciók titkosítása a web.config fájlokban. A web.config fájlok zárt adatai gyakran titkosítottak, amikor az alkalmazást a kiszolgálókra telepítik. Például a connectionString szakasz titkosítva megakadályozhatja, hogy a felhasználónév és a jelszó kiszivárogjon az adatbázisba. Ahelyett, hogy a web.config fájlt külön-külön titkosítanák az egyes kiszolgálókon, ami bonyolítja a telepítési folyamatot, létrehozhat egy titkosított web.config fájlt, és telepítheti azt minden kiszolgálón. Ehhez hozzon létre egy RSA kulcskulcsot, és importálja az összes webkiszolgálóra.
Az egyedi kulcsok létrehozásáról és az alkalmazások beállításainak beillesztéséről további információt a Microsoft Tudásbázisban talál. További információ az RSA kulcs tartály létrehozásáról: "Biztonsági RSA kulcstartók importálása és exportálása konfigurációhoz" az MSDN webhelyen.