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: ,


  • URL rövidítés kódból 1 - TinyURL

    Balássy György (MS RD, ASP.NET MVP, MCTS) Az egyik projektünkben string hossz limitek között vergődve arra jutottunk, hogy a felhasználó által megadott URL-ek rövidítésével nyerünk pár karakternyi helyet. Nosza meg is néztük a TinyURL URL rövidítő szolgáltatást és szembetaláltuk magunkat a világ legegyszerűbb API-jával. Tovább »
  • IE9 Jump List készítése

    Fekete Krisztián Az előző alkalommal bemutattuk, hogy az IE 9-ben böngészett weboldalak pinnelhetők. A taskbarra ráhúzott vagy hozzáadott alkalmazásokat ebből kifolyólag testre szabhatjuk pl.: Jump List menü készítésével, amely a Windows 7 egyik újdonsága. A Jump List-et a taskbaron található alkalmazás ikonjára jobb gombbal kattintva jeleníthetjük meg, ahol az egyes menüpontok a programhoz tartozó legfontosabb műveletek gyorsabb elérését segítik. 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