Category Archives: IIS

IIS lassulás probléma – megoldás

Annak idején írtam róla, hogy egy cégnél a web szerverek és a mögöttük levő webszervizek közötti kommunikációban jelen van egy 200ms-os plusz késleltetés, amire nem találtunk racionális magyarázatot.
Semmilyen eddig bevált eszköz, profilerek, WinDebug, Dynatrace, logok elemézése nem adott magyarázatot a jelenségre.
A Google a Nagle és a Delayed Ack irányába tolta a vizsgálódást.
Végül wiresharkkal alaposan kielemezve a forgalmat kiderült, hogy a protokoll leírással szemben csak 200ms késleltetéssel küldtek Acknowledge-et egymásnak a felek, ez adott késleltetést minden híváshoz. Miután a delayed ackot kikapcsoltuk mindkét oldalon, a jelenség megoldódott. A megoldás szerintem csak workaround, mivel a tcp protokol rfcje alapján nem így kellene működni a hálózatnak, vagy a Windows vagy a VMWare network card driver a bugos.

Röviden, mi zajlik itt le. A kliens (web app) TCP kommunikációt kezdeményez a webszerviz felé. A TCP protokollban minden csomag vételét meg kell erősíteni a másik oldalnak. Esetünkben olyan kicsi kérések mentek a szerviz felé, hogy belefértek egy hálózati csomagba. A Nagle algoritmus már eleve bufferelhetné a hívó oldalon a csomag kiküldését, de ezt úgy néz ki a generált webszerviz proxy kikapcsolja a Naglét, így ez nem okozott problémát.
Átmegy a kérés a szervizbe. Onnan egy acknowledgenek kell visszamenni a kliensre, jelezve, hogy a szerviz megkapta a csomagot. Ezt nem akarja visszaküldeni a szerviz azon mód, pár bájt miatt nem akar egy teljes csomagot visszaküldeni. A protokol alapján vár arra, amíg amúgy is küldene valamit vissza a kliensnek, és annak a hátára rakná rá az acknowledget (piggybacking).
Esetünkben volt sok kérés, lett volna alkalma visszaküldeni gyorsan a megerősítést, de nem tette. A protokollban van egy másik elem is. Ha eltelik 200ms, akkor ha eddig nem volt alkalmunk visszaküldeni a választ, legalább 200ms múlva meg kell tenni. Ez a delayed ack. Meg is tette a szerver, de ezzel minden egyes kérésre az ackot 200ms múlva küldte csak vissza. A kikapcsolással pazarló módon minden egyes csomagot azonnal visszajelez a szerver, azaz kikapcsoltuk ezt az optimalizálást, de cserébe a bugos késleltetés kiesett.
Összegezve, a válasznak vissza kellett volna menni más kérésekre adott válaszok hátán, de nem mentek vissza, ezért állítom, hogy ez bug, a delayed ack kikapcsolás csak workaround, de legalább megoldotta a késleltetést.
Két kép, ami szemlélteti a hibát.
Az első egy csatornán a kommunikáció lépéseit mutatja meg (a http keepalive miatt sok kérés meg át egy tcp csatornán). Látható, hogy nagyon sok kérésre csak 200ms múlva jön meg a válasz.

A második képen sok kérés ackjának maximuma látható. Jól megfigyelhető a “fék” hatása.

Sajnos nincs kéznél képem, de a delayed ack kikapcsolása után lemegy pár száz mikro!secre a válasz, mivel ilyenkor buzgó módon azonnal megy vissza az ack.

400 Bad Request – Request header too long

Reporting Services elérése közben jött a hiba, de IIS alatt is ugyanez lett volna a gond. A hiba oka, hogy a http.sys alapban 16kban korlátozza a http request hossszát, egy AD user access tokenje viszont nagyobb lehet ennél. Mivel a Kerberos auth (majdnem minden auth) a http headerben tolja át az auth infót, ha egy user nagyon sok csoportnak tagja az auth header nagyon nagy lehet. Esetünkben akinél jól ment 7k volt az össz kérés hossz, a beteg usernél 26 (Fiddlerrel néztük meg). Ez több mint 16, így természetes, hogy a http.sys kivágta.
A megoldás a limitek felemelése volt (MaxFieldLength és MaxRequestBytes registry értékek).
Bővebben az okról és a beállításokról itt. A beállítás a http stackre vonatkozik, user módú fogyasztótól (IIS, SQL Server, stb.) függetlenül.
Még egy dolog. A 2. cikk szerint újra kell indítani a http valamit. Ez látszólag szerviz, de nem az, hanem device driver. Mint ismert, 2003-tól és XP SP2-től a http.sys kernel módú driver fogadja a http kéréseket, ehhez írtak device drivert, mivel NT alatt így lehet kernel módban futtatni valamit. A service-ek között tehát nem látszik, hanem a Device Mangerben a Non Plug and Play kategória alatt lesz. Csak akkor hajlandó leállni, ha semmilyen user módú processz nem épít rá. Az összes http kiszolgáló erre épít, így az IIS és a Reporting Services is (meg az SQL Server http endpointjai, stb.). Esetünkben nem akart leállni, de a Reporting Services leállítása után azonnal leállt. Megúsztunk egy gép restartot, ami fájt volna, mivel ezen volt az SQL Server is.

Webkiszolgálás sebességmérése logparserrel

Elég kevesen használják a logparsert, pedig szenzációs. Azt képzeld el, hogy szöveges adatokon tudsz sql lekérdezéseket futtatni. Pl. IIS logokon. Relációs adatbázis nélkül, és elég gyorsan. Van még kérdés? Nagyon jó, na. :)

Ha pl. szükséged van egy baseline-ra mielőtt nekiállnál optimalizálni a website-ot, jó lenne tudni az átlagos kiszolgálási időket mindenféle tartalomra, pl. aspxekre, akkor a logparserrel pillanatok alatt ki lehet nyerni statisztikákat.

Bővebben itt.

Microsoft Application Request Routing for IIS 7

Érdekes kis apróságra akadtam. A fenti cucc egy alkalmazásszintű router, amivel IIS-ekből álló webfarm gépeire lehet szelektíven ráirányítani a terhelést.
Tehát nem azt csinálja, mint az NLBS, hogy IP szinten dönt, hanem általunk megírt logika alapján osztja szét a terhelést a webszerverek között, ami adott esetben igen hasznos lehet.
Még nem látom át hogyan lehet ezzel kiküszöbölni a single point of failure-t, de rajta fogom tartani a szemem.

# HTTP based routing decisions
Unlike hardware load balancers that make the routing decisions at the IP level, Application Request Routing makes the routing decisions at the application level. Working with URL rewrite module, powerful routing rules can be written based on HTTP headers and server variables.
# Load balance algorithms
A user selected load balance algorithm is applied to determine which content server is most appropriate to service the HTTP requests. Six algorithms are provided.
# Health monitoring
Both live traffic and specific URL test are used to determine the health of content servers. A set of configuration parameters are provided to define the meaning of server health.
# Client affinity
Using a cookie, Application Request Routing can affinitize all requests from a client to a content server. It differentiates the clients behind NAT, so each client is treated independently. This feature requires that the clients accept cookies.
# Host name affinity
“Host name affinity” is a specific feature for shared hosters. It changes the deployment topology to minimize and streamline administration and to create additional business opportunities.
# Multiple server groups
Application Request Routing can manage multiple server groups, which are logical groupings of content servers in an environment. This feature allows Application Request Routing to be used in pilot management and A/B testing scenarios.
# Management and monitoring via UI
All configuration settings and aggregated runtime statistics of Application Request Routing are managed and viewable via IIS Manager.
# Failed Request Tracing Rules
Specific traces have been added to quickly troubleshoot and diagnose Application Request Routing.

Webszerver compression – lassít vagy gyorsít?

Nem kérdés, hogy a kliens jelentősen gyorsabban hozzájut a tömörített tartalomhoz, pl. a google lapjai többek között ezért gyorsak.
De mekkora hatással van ez a szerverre? Mennyire lassítja azt le? Eddig az volt a fejemben, hogy ez a szükséges rossz, a szerver procija gőzerővel tömörít, ezért bár a kliens megnövelt felhasználó élményt él át, a szerver ki lesz terhelve. De NEM és nem!

Mivel a tömörített tartalmat letárolja az IIS, ezért ha már egyszer lezajlott a tömörítés, a továbbiakban már csak mint statikus fájlt kell kiszolgálni a szervernek, ráadásul sokkal kisebbet, mint az eredeti. Ennek eredményeképpen nem csak, hogy jobb lesz az élmény a kliensen, de még a szerver is örül. Ez a nem semmi, mi? Persze dinamikus tartalom esetén már sokkal jobban meg kell gondolni, ott általában nem megy az újrahasznosítás.

Mindezt lehet kombinálni SSL-lel is, ekkor is örül a szerver, mert kisebb tartalmat kell titkosítani, és ellentétben a tömörítéssel a titkosítás valóban nagyon proci intenzív. Tessék megnézni a linkelt cikket, tanulságos.
Szeressétek a tömörítést, nem kerül semmibe bekapcsolni (IIS7-en, IIS6-ban nincs kivezetve a GUI-ra).

Őstermelők és egyéb farmtulajdonosok figyelmébe: MSDeploy

Az IIS7-ben van ugye a közös konfig, amit előreláthatóan demózni fogok majd márciusban a Launch-on. Ehhez már csak egy dolog kellett a webfarmoláshoz, a tartalom szinkronizálásának lehetősége. Most már ez is egyenesben van. Gratula az IIS7 bandának, tehetséges bagázs ez. Igyeszek összerakni egy olyan demót, amiben lesz több gép, shared config és MSDeploy is. Ezúttal igyekszek nem szívatni magam, mint az előző előadás során.

IIS7 Config – appcmd.exe

Vistán, egy program telepítése közben futott a process monitor, és akkor láttam, hogy használja az appcmd.exe-t. Rákerestem már, kiderült, hogy ő az IIS7 konfig utilja, az eddig vbscriptek helyett.

A szokásos site, appdomain, stb. mellett érdekes dolgokat is tud, pl. kilistázni az éppen futó kéréseket. Eddig ez tudomásom szerint nem lehetett, vagy talán a 2003 SP1-ben igen? Nem tudom.

De a cikk nagyon jó bevezető az eszközbe.