ETags kontra webfarm

Ki látott már olyat, hogy miután új webszerver kerül egy farmba megnő a hálózati forgalom, sőt meghal a böngésző cache? Pedig IIS 7 előtt ez történik.

A böngésző cache elsősorban úgy működik, hogy az első lekérdezéskor a szerver visszaküldi az adott erőforrás (kép, oldal stb.) utolsó módosításának dátumát a Last-Modified fejléc mezőben, amit a böngésző az ismételt lekérdezéskor egy If-Modified-Since fejléc mezőben visszaküld a szervernek. A kiszolgáló csak akkor küldi le a teljes fájlt a kliensnek, ha a fájl frissebb, egyébként HTTP 304 Not Modified választ küld body nélkül.

Csakhogy utazik egy másik pár fejléc mező is, az ún. entity tag, azaz ETag. Az IIS valami ilyesmit küld vissza:

ETag: "0ba4e9b5277c71:5897"

A következő kérésnél pedig ezt az értéket így küldi vissza a kliens:

If-None-Match: "0ba4e9b5277c71:5897"

A válasz a dátumos megoldáshoz hasonlóan egyezés esetén 304, eltérés esetén 200 + az új tartalom. Az ETag mező tartalmára a HTTP 2616 Section 3.11 szerint gyakorlatilag csak annyi megkötés van, hogy egy idézőjelek közé zárt egyedi értéket tartalmazzon. IIS esetén ez FileTimeStamp:ChangeNumber értékekből áll, Apache esetén más formátumú a tartalom: inode-size-timestamp, például:

ETag: "ef15-424-eda08740"

Mindkét esetben az a probléma, hogy a ChangeNumber és az inode részeket a fájlrendszer tartja nyilván és az értékük gépről gépre jó eséllyel eltérő. Azaz ha csak egyetlen webkiszolgálónk van, akkor semmi probléma, amikor azonban egy NLBS farmot építünk és beteszünk egy második kiszolgálót, azon szinte biztos, hogy eltérő lesz a ChangeNumber és az inode érték. Következésképp míg egy kiszolgáló esetén a böngésző lelkesen a saját gyorsítótárából töltötte a tartalmat, a második szerver üzembe állítása után - ha a két kérés más szerverre esik be, akkor  - kénytelen letölteni a fájlt, hiába azonos mindkét szerveren. A végeredmény nagyobb hálózati forgalom és lassabb renderelés még akkor is, ha van If-Modified-Since fejléc, ugyanis az If-None-Match elsőbbséget élvez.

A megoldás nyilván az, hogy meg kell szabadulni a gépfüggő részektől:

  • IIS 5 (ugye már senki nem használ ilyet?!) esetén az mdutil.exe-vel lehet szinkronizálni az ETag értékeket, ld. KB 922733.
  • IIS 6 esetén be lehet állítani egy fix ChangeNumber értéket, ld. KB 922703. Itt előfordult néhány bug, érdemes megnézni a 823544 és a 900245 KB cikkeket is.
  • Apache esetén a FileETag direktíván keresztül lehet beállítani, hogy az ETag fejléc milyen fájl tulajdonságok alapján képződjön, ld. Apache Core Features.

A jó hír az, hogy IIS 7 esetén ezzel egyáltalán nem kell foglalkozni, ugyanis a ChangeNumber elveszítette jelentőségét, az értéke mindig fixen 0. Vegyes farm esetén a fenti módszerekkel ezt a 0 értéket kell IIS 6-on is beállítani. HTTP 1.1 esetén az elvárt viselkedés az, hogy a szerver küld ETag és Last-Modified fejléceket is, tehát teljesen nem célszerű megszabadulni tőle.

Összefoglalva tehát egy gép esetén nincs gond, több gépes farm esetén IIS 7 előtt figyeljünk oda erre a fejléc mezőre.



Balássy György (MS RD, ASP.NET MVP, MCTS)

Balássy György (MS RD, ASP.NET MVP, MCTS) Villamosmérnök, a BME Automatizálási és Alkalmazott Informatikai Tanszékén webportálok fejlesztését oktatja. 2000 óta foglalkozik a Microsoft .NET platformjával, melynek meghonosításában jelentős szerepet vállalt előadóként, konzulensként és A .NET Framework és programozása című könyv társszerzőjeként. Az MSDN Kompetencia Központon belül a Portál Technológiák Csoport vezetője, szakterülete web alapú rendszerek fejlesztése és üzemeltetése. 2004-ben Magyarországon elsőként kapta meg a Most Valuable Professional címet, majd 2005 óta a Microsoft magyarországi regionális igazgatója. Publikációi a Technet Magazinban, az MSDN Kompetencia Központ honlapján és szakmai blogjában olvashatóak.

2010.01.04. 21:54:07 | Permalink | Hozzászólások: 0 | Tárgyszavak: ,


  • Nyelvi szegénység

    Balássy György (MS RD, ASP.NET MVP, MCTS) Elárasztanak a desktopok, már szinte mindent desktopnak hívunk - vagyis inkább az amerikaiak -, aminek köze van az asztalhoz vagy éppen nincs köze a hordozhatósághoz. Tovább »
  • SharePoint 2010 BDC adatbázis neve

    Balássy György (MS RD, ASP.NET MVP, MCTS) A SharePoint 2007 idején már szörnyülködtem egy kicsit azon, hogy milyen barátságtalan nevet kapnak az adatbázisok az odacsapott GUID-dal a végén. A rossz hír az, hogy ez a tünet megvan SharePoint 2010 esetén is, ráadásul több adatbázisunk is van. Tovább »


Írja meg Ön is véleményét!


Hozzászólásokat csak regisztrált, bejelentkezett felhasználóktól tudunk elfogadni!

Hozzászólások