Soci (Soczó Zsolt) szakmai blogja

2017.12.27.

IIS lassulás probléma – megoldás

Filed under: IIS,Optimalizálás,Szakmai élet — Soczó Zsolt @ 11:21

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.

2015.04.03.

Startcom SSL cert importálása IIS alá

Filed under: IIS,IIS7,Security,Szakmai élet — Soczó Zsolt @ 13:43

A Startcom SSL-lel ingyen lehet teljesen valid certificate-eket generálni. A generálás kimenete viszont nem egy Windwos által fogyasztható cert pár lesz, hanem egy cert kulcs nélkül és külön egy kulcs fájl.

Itt leírják, hogy lehet ezt az IIS által is ehetővé alakítani, a lényeg:

openssl pkcs12 -export -in foo.crt -inkey foo.key -out foo.p12

2012.08.28.

400 Bad Request – Request header too long

Filed under: IIS,SQL Server,Szakmai élet,Windows,Winternals — Soczó Zsolt @ 17:42

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.

2010.05.12.

LogParser példák

Filed under: Adatbázisok,IIS,IIS7,Szakmai élet — Soczó Zsolt @ 18:43

Durva gyors jószág ez a logparser, SQL Server alatt alaposan alá kellene indexelni az adatoknak, hogy ennyire gyorsan kezeljük őket.
Jó példák hozzá, meg itt és itt.

2010.05.10.

Home Windowsokon nehézkes IIS-ben fejleszteni

Filed under: Debugging,IIS,IIS7,Szakmai élet — Soczó Zsolt @ 10:17

Nincs bennük Windows Auth, így nem megy a debugging se. Ref. Nagy cumi ez. Ha valaki tud rá megoldást, érdekelne. (Nekem ultimate-em van, így nem gond, de már a 2. ismerősöm fut ebbe bele.)

2009.02.19.

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

Filed under: IIS,IIS7,Optimalizálás,Szakmai élet — Soczó Zsolt @ 15:05

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.

2009.02.04.

Microsoft Application Request Routing for IIS 7

Filed under: IIS,IIS7,Szakmai élet — Soczó Zsolt @ 15:30

É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.

2008.03.04.

Internet Information Services (IIS) 7.0 Manager

Filed under: IIS,IIS7,Szakmai élet — Soczó Zsolt @ 19:24

Na kérem, ezzel lehet már XP-ről is távolról, HTTPS-en keresztül reszelni egy Windows 2008 IIS7-et.

2008.02.27.

Webszerver compression – lassít vagy gyorsít?

Filed under: IIS,IIS7,Szakmai élet — Soczó Zsolt @ 22:05

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).

2008.02.26.

Mit jelent a Start, Stop, Recycle az IIS7-nél

Filed under: IIS,IIS7,Szakmai élet — Soczó Zsolt @ 21:16

Starting, stopping and recycling IIS 7.0 Web sites and application pools

2008.02.24.

IIS 7.0 – the number one reason customers want Windows Server 2008

Filed under: IIS,IIS7,Szakmai élet — Soczó Zsolt @ 18:26

Érdekes, mi?

IIS7 a nyerő :)

2008.02.19.

MSDeployhoz Vista SP1 kell

Filed under: IIS,IIS7,Szakmai élet,Vista,Windows Server 2008 — Soczó Zsolt @ 23:53

Mert őkelmét Windows 2008-on tesztelték, ami meg azonos modulokat tartalmaz, mint a Vista SP1. Van motivációm, hogy felrakjam az SP1-et.

2008.02.18.

Breaking Changes for ASP.NET 2.0 applications running in Integrated mode on IIS 7.0

Filed under: IIS,IIS7,Szakmai élet — Soczó Zsolt @ 15:50

Lista.

2008.02.10.

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

Filed under: IIS,IIS7,Szakmai élet — Soczó Zsolt @ 15:05

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.

2007.12.15.

IIS7 feljlesztői újdonságok a channel 9.hu-n

Filed under: IIS,IIS7,Szakmai élet — Soczó Zsolt @ 12:30

A mesélő ismerős lesz. :)

Nekem most meg se mukkant a video, de letölteni le lehetett volna. De mivel nem szeretem visszanézni magam filmeken, nem tettem. :)

2007.08.09.

IIS és .NET 2.0 interjú kérdések

Filed under: .NET,ASP.NET,IIS,IIS7,Szakmai élet — Soczó Zsolt @ 14:34

Jók, érdekesek, némelyik rázós.

2007.04.26.

SSL FTP az IIS7-ben

Filed under: IIS,IIS7,Szakmai élet — Soczó Zsolt @ 11:41

Hú, de nagyon hiányzott ez már a hostereknek (is).
A Longhorn server B3-ban már benne lesz (ma, asszem), a Vistának még nem része.

Hírforrás.

2007.04.19.

TLS 1.0 kikapcsolása IIS alatt

Filed under: IIS,Szakmai élet — Soczó Zsolt @ 15:32

Ha a webszerver bepróbálkozna a régi TLS használatával, itt le van írva, hogy lehet lebeszélni róla. Ez akkor állhat elő, ha nincs kikényszerítve az SSL, de mégis https-sel hivatkoznak egy oldalra.

2007.01.18.

IIS7 Config – appcmd.exe

Filed under: IIS,IIS7,Szakmai élet — Soczó Zsolt @ 14:42

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.

2006.12.08.

Powershell bevezető

Filed under: .NET,IIS,PowerShell,Scripting,Szakmai élet — Soczó Zsolt @ 09:29

Némi IIS7-tel fűszerezve. 10 perces kis olvasmány, az a csóka műve, aki az msdn magazinban a tesztelős cikkeket írja. Értelmes ember, értelmes cikk.

Powered by WordPress