Soci blog

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.

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

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.

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

http://learn.iis.net/page.aspx/208/fastcgi-with-php/

Windows 2008 kell hozzá, mert ugye ez IIS7 fícsör.

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

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

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

Érdekes, mi?

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.

Lista.

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.

Szerintem ez zseniális.

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

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

Hibakeresésnél bosszantó, hogy az iis csak időnként flush-olja a logot, így várni kell perceket, mire megjelenik egy kérés nyoma (amúgy teljesítmény okokból ez ésszerű).

IIS7-ben a megoldás a flusholásra:

netsh http flush logbuffer

Forrás.

Aranyos kis appcmd példák, csövekkel. Ötletesek, így még nem láttam használni az appcmdt.

Lement a konferencia, kemény volt. Nem a konferencia, hanem a felkészülés. Írtam már, hogy esküdtek össze ellenem az elemek. Szó szerint, mert még az egerem elemei is kimerültek délre, így a helyi ABC-ben vettem bele gyorsan.
Szerencsére szinte minden működött jól, így tempósan tudtam adagolni a témát. Lehet, hogy volt akinek gyors volt, de én azokat az előadásokat szeretem, ahol sok a tartalom, zsibbad utána az ember agya, annyi újat hallott. Ez szerintem ilyen volt, és ennyi infót csak hadarva lehet elmondani. :)

A prezentációt és a demó fájlokat feltöltöttem , használjátok egészséggel. Van benne powershell cucc is, ez az első ps programom, de azért talán lehet belőle tanulni (nem 3 sors cat alma.txt :).

Update: Zokszigen kérésére felraktam pdfben is a prezentációt.

De úgy, igazán, nem VSből matyizva.
Kár, hogy nem fejlesztők lesznek a konferencián, így nem tudom bemutatni, imádom az ilyen hardcore izéket (mindenféle hardcore izéket szeretek :).
Nem baj, vannak ravasz tippjeim adminoknak is.

Na és, miért érdekel ez egy webfejlesztőt? Nos, egyrészt eddig nem így működött. A változtatás miatt egyes appok nem tudnak írni a temporary könyvtárba, mert a temp nem az általános temp könyvtár már, hanem a service account tempje, amibe viszont sokszor nincs joga írni az imperszonált akármilyen accountnak. Aki régi ASP-t futtat, sőt, szerintem aki webszervizt hív asp.net kódból, az beleszalad ebbe (az asp.net XmlSerializer runtime kódgenerálást csinál, amelyhez a kiinduló forráskódot a tempben állítja össze, hacsak sgen-nel nem generáljuk le előre a szerializáló osszomblit).

No, de miért jó ez a változtatás? Hivatalos okot még nem olvastam, de van egy tippem. Az SQL Server Expressnek van egy olyan üzemmódja, amelyben minden hívó processz kap egy kis SQL szerverkét. A User Instance=True connection string hatására működik így. Ilyenkor minden hívó kap egy saját példányt, abban prütykölhet. Ez egyrészt azt jelenti, hogy kap egy dedikált, a saját nevében futó SQLserver exét, másrészt a rendszeradatbázisokból kap egy másolatot. Hová? Hát a profile-jába. No, ezzel vissza is értünk a miért jó a profile webes környezetben kérdésre. E miatt nem tudtam megoldani IIS6 alatt, hogy hosztolt webkörnyezetben ebben az üzemmódban használjam a 2005-öt. Ezek szerint van remény, hogy Windows 2008-ban ez jól működjön.

Ps. Bálint kisfiam szerint “busztustalan meleg van”. :)