Windows - Az Internet Information Services (IIS) 5.0 szerver működési sebességét meghatározó tényezők

IIS 3. rész

Ez a cikk az IIS 5.0 webszerver sebességét befolyásoló hardver és szoftver összetevőkről szól. Ezen kívül bemutatunk néhány tesztelésre használható programot. Nem mondunk sok újat azzal, hogy ha egy szerverben minél több a memória, minél gyorsabb a processzor, annál gyorsabban működik. De előállhatnak olyan extrém esetek, amikor ez mégsem így van. Nézzük a hardver elemek hatását a szerver működésére.

Memória:

A memóriára érvényes a több - jobb elv, és természetesen a maximális működési frekvenciája is jobb, ha minél magasabb. A Windows létrehoz a merevlemezen egy virtuális memóriát és ha a RAM megtelik, a további adatokat oda írja ki. Ennek a módszernek az a legnagyobb hátránya, hogy a merevlemez sokkal lassúbb mint a RAM. Az az ideális, ha nem kell egy folyamatnak vagy adatnak sem a virtuális memóriába kerülni. Ez egy nagyobb forgalmú szerver esetén nehezen kivitelezhető. A következő IIS elemek memóriában tartására sokat javít a szerver sebességén:
IIS programkód:
INETINFO.EXE; 2,5 MB, de a hozzá kapcsolódó szálakkal együtt ennek a többszöröse is lehet. Minden bejelentkezett felhasználó egyetlen kapcsolata kb. 10 KB, tehát 1000 kapcsolat esetén 10 MB.
Objektum cache:
Az INETINFO.EXE-hez kapcsolódik. Ebben található a webhely állományainak azonosító száma, a könyvtárszerkezet és a fájlok listája. Méretét az IIS dinamikusan változtatja.
Template cache:
Méretét tekintve kicsi, alapvetően csak pointereket tartalmaz és a dllhost memória területén található. Az IIS 4.0-ban végtelen számú fájlmutatót tartalmazhatott, ezért ott gyakran megtelt a memória. Az IIS 5.0-ban 256-ra csökkentették a korlátot.
Script Engine Cache:
Előfordított (precompiled) ASP scriptek tárolóhelye, szintén a dllhost tárterületén. Kapacitása az IIS 4.0-ban 20, az 5.0-ban 120 fájl.
File System Cache:
A statikus weblapok fájljai tárolódnak itt. Az IIS az Object cache-el néha közösen használja.
Log files:
Ezek a napló fájlok. Ha úgy vannak beállítva, hogy minden eseményt rögzítsenek, akkor nem kívánatos a merevlemezen tartásuk.
TCB (Transmission Control Block) tábla:
Az aktív TCP kapcsolatok listája, helyi és távoli socket számokkal.
HTTP kapcsolatok tárolója:
Az aktív HTTP kapcsolatokat tárolja.
Pool Threads
Ebben pedig az IIS szálak tárolódnak.

Az lenne az ideális, ha a fentiek mind elférnének a RAM-ban. Az INETINFO.EXE, ha nincs elég memória, bizonyos részeit (az EXE-n belül) kiteszi a merevlemezre. Az IIS memória felhasználása a rendszerrel való szoros integráltsága miatt legegyszerűbben a "Feladatkezelő"-ben a "Teljesítmény" lapon ellenőrizhető. A szálak külön-külön nem, tekintve, hogy léteznek rejtettek is. A fenti felsorolásból kitűnik, hogy az összes memóriaigény függ az IIS által kezelendő fájloktól, a felhasználók számától és tevékenységétől és a használt adatbázisok méretétől. Az eddig elmondottakat számszerűsítve minimum 256 MB RAM-ra lesz szükségünk, ha nagy forgalmú a webhelyünk (több ezer látogató naponta) akkor lehetőleg ennél több.
Mi van abban az esetben, ha a meglévő memória kevés és további memória bővítés nem megoldható? Optimalizálni kell a memória használatot: <
  • Az összetartozó fájlokat tároljuk egy helyen - egy partíción, ne legyen széttöredezettség.
  • RAID használata a fájlok elérésére gyors beolvasást és cache-t (ami nem a rendszermemória) nyújt.
  • Lehetőleg ne használjunk CGI scripteket, sok processzor idő és memória kell hozzá.
  • Növeljük a virtuális memória méretét (pagefile.sys), akár minden partícióra tehetünk egyet.
  • Az operációs rendszer memória menedzselését hálózati alkalmazásokra kell optimalizálni: Helyi kapcsolat > Fájl- és nyomtatómegosztás Microsoft Networks-höz > Tulajdonságok > Átvitel optimalizálása hálózati alkalmazásokra.
  • Az IIS-en kívül csak azokat a programokat futtassuk a szerveren, amelyekre feltétlenül szükségünk van.

Processzor (CPU):
Az IIS több szálat futtató alkalmazás, ezért nagyobb a processzor terhelése, mint egy hagyományos programnak, de ugyanakkor megadja a lehetőséget a párhuzamos feldolgozásra ezért többprocesszoros rendszerben optimálisan képes működni. Processzoronként max. 4 szál feldolgozása történik. Ha ez nem használja ki teljesen a processzor teljesítményét, növelhetjük ezt az értéket. Ehhez a regisztrációs adatbázisban a következőt kell beállítanunk:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters\MaxPodThreads és az érték 2 és 20 között legyen.
Abban az esetben, amikor a webhelyünk nem használja ki teljesen a processzor kapacitását, akkor egy második, felesleges processzor csökkenti a teljesítményt. Ez az egyik tényező, amire a bevezetőben utaltunk. Minden egyes kapcsolat növeli a terhelést ezért egy bizonyos számú kapcsolat felett kialakulhat valahol a rendszerben egy szűk keresztmetszet (RAM, CPU, hálózati kártya stb). Erre a megoldás több szerver használata egy webhely kezeléséhez, ezt hívják fürtözésnek (clustering) és a Windows 2000 Advanced Server képes megvalósítani.
Nézzük mivel optimalizálhatjuk a processzor kihasználtságát:
  • Javíthatunk a teljesítményen a "HTTP Keep - Alives" használatával, amely életben tartja a kapcsolatokat és nem kell minden kérésnél felépíteni majd bontani. Beállítható az adott webhelyen a Tulajdonságok > Webhely > HTTP keep-Alive engedélyezése ponton. Hátránya, hogy foglalja a sávszélességet. Támogatja az IIS 1.0, az InternetExplorer 2.0, a Netscape Navigator 2.0 és későbbi verzióik.
  • Csökkentsük a CGI scriptek számát vagy futtassuk szálakban őket. Ehhez ismét a regisztrációs adatbázishoz kell fordulnunk és létre kell hozni egy új DWORD-t nullás értékkel a HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\w3svc\Parameters\UsePoolThreadForCGI helyen.
  • Válasszunk olyan processzort amelyiknek nagyobb az L2 cache-e (2MB minimum az ideális).
  • Több processzoros rendszerekben legyen annyi hálózati kártya a gépben, ahány processzor. Ez csak nagy terhelésnél hasznos, mert minden hardverelem erőforrást igényel (sok hálózati kártya és egy processzor nagyon rossz választás).
  • A hálózati kártyák meghajtó programjai jó, ha támogatják az interrupt mode-ration-t. Így nem árasztják el a processzort felesleges megszakításokkal.
  • Csökkentsük az egyidejű kapcsolatok számát: a webhelyen állítsuk be a Tulajdonságok > Webhely > Kapcsolatok "Legfeljebb X kapcsolat" mezőben azt az értéket ami még elfogadható sebességű szolgáltatást tesz lehetővé. Ez minden szerveren más és tulajdonképpen csak tapasztalati úton juthatunk el az ideális értékhez.
  • Optimalizálni kell a webhelyet: optimális nem túlságosan terhelő adatbázis kapcsolatok, ISAPI vagy ASP oldalak a CGI helyett, nem túl nagy bitképek, lefordított komponensek használatával. Továbbá SSL-t és dinamikus weboldalakat csak tényleges szükség esetén alkalmazzunk.

Hálózat:
Természetesen a minél nagyobb sávszélesség a jobb, mindenki számára ideális megoldás lenne egy dinamikusan változó sávszélesség, de ez inkább csak elméleti síkon létezik. A hálózati forgalmat a Server és az Advanced Server-hez kapott Network Monitor programmal tudjuk ellenőrizni. A webhely sávszélesség használatát az IIS konzolon a webhely Tulajdonságok > Teljesítmény > Sávszélesség szabályozásának engedélyezésénél tudjuk állítani. Erre akkor lehet szükségünk, ha több webhelyet működtetünk a szerveren, így nem tudják egymás elől elvenni a sávszélességet.
További két tipp a jobb kihasználásra:
  • Növeljük a kapcsolatok várakozási sorának a hosszát:
  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters\ListenBackLog paraméter növelésével. Legyünk biztosak abban, hogy a RAM és a CPU is elbírja ezt.
  • HTTP Keep-Alive használata.

Merevlemez:

Az adattároláson kívül annyi szerepe van - mint említettük - ha kevés a memória, az adatok kikerülnek a merevlemezre, ezért gyors merevlemezre van szükségünk. Adatbázisok használata esetén, az ebben való keresést is erősen befolyásolja. Fontos, hogy ne legyen fragmentált, használjuk a lemeztöredezettség mentesítő programot. További előnyökkel jár az NTFS fájlrendszer használata, mert plusz biztonsági lehetőségekhez jutunk a révén.

Szoftver:
Az előbbiekben már többször utaltunk szoftver optimalizációs beállításokra. Egészítsük ki ezeket:
  • A statikus weblapok gyorsabban működnek, mint a dinamikusak. A dinamikusakat "hatásosan" kell megírni, kerülve a felesleges kódokat. A különböző forrásból összeválogatott scriptek általában kevésbé hatásosak, mint a célirányosan a feladathoz készítettek.
  • Használjuk COM objektumokat az ASP helyett, mert gyorsabb és az ASP átalakítható COM-má.
  • Ne használjunk ASP nyomkövetést, csak ha szükséges.
  • Állítsunk be a weboldalaknak lejárati időt - ha a tartalma megengedi - a böngésző kevesebbszer kéri le.
  • Ne állítsuk egyik cache-t sem nullára.
  • Ha a webhelyünk több porthoz csatlakozik, mindegyikhez keletkezik egy BackLog naplózó szál. Tiltsuk le a BackLog monitort. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters\DisableBackLogMonitor, ezután újra kell indítani az IIS-t.
  • Az SSL használatával a fájl letöltés 10-100-szor lassúbb, mint SSL nélkül.

Tesztelésre használható eszközök:

Van egy remek kis program, amely a Windows 2000 Professional-ban is megtalálható a Felügyeleti eszközök > Teljesítmény ikonra kattintva. A Rendszermonitor > Hozzáadás gombjával rengeteg figyelni kívánt paraméter beállítható, hálózatban másik gépet is ellenőrizhetünk vele.
Parancssorban a NETSTAT programmal az aktív hálózati kapcsolatok listájához jutunk. Ehhez az "-a" kapcsolóval kell meghívni. Az "-e" kapcsoló részletes ethernet statisztikát eredményez. Protokollonkénti statisztikát és az útválasztó táblát is megjeleníthetjük. A "NETSTAT /?"-el kiírathatjuk a használható kapcsolók listáját.


Az IIS alapjai cikksorozat