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


  • Lockdown Policy Prevents This Request

    Balássy György (MS RD, ASP.NET MVP, MCTS) Az egyik webalkalmazásunkkal kapcsolatban több megkeresés érkezett, hogy a felhasználókat nagyon zavarja a sok tanúsítvány figyelmeztetés, ezért jó lenne a Root CA tanúsítványát közvetlenül letölthetővé tenni a bejelentkező oldalról. Fogtam hát a tanúsítványkiadó tanúsítványát .cer formátumban, felmásoltam a webszerverre, majd kissé meglepődve bámultam a böngészőben megjelenő 404 – Not Found hibaüzenetet. Tovább »
  • CommandArgument CheckBoxnak

    Dávid Zoltán Az ASP.NET CheckBoxnak sajnos nincs “Value” vagy “CommandArgument” jellegű tulajdonsága, amihez adatot köthetnénk, hogy azt egy CheckChanged jellegű eseménykezelőben elérjük. Ha mégis ilyesmire vágyunk innováljunk magunknak egy új attribútumot (például elemIDdata-id), a CheckBox markupjába, aztán érjük el szerveroldalon a CheckBox Attributes tömbjén keresztül. 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