A weboldalak két különböző típusú tartalommal rendelkeznek.
Van maga a HTML kód, ami zömmel dinamikus részekből tevődik össze. A weboldalt leíró nyelv kódjából (ez általában valamilyen script vagy programnyelv - PHP, Java, Ruby, Perl, stb.), és az adatbázisban tárolt szöveges elemekből. Ez utóbbiak gyakran változnak, a különféle feltételek miatt ugyanazon a webcímen más-más információk jelenhetnek meg.
A weboldalak azonban nagy számú statikus elemet tartalmazhatnak. Java scriptek, stíluslapok, médiatartalmak, melyeknek elérési útvonalán általában ugyanaz az adathalmaz érhető el.
Ezeket az elemeket célszerű más címen (URL-en) elérhetővé tenni.
Miért?
Amikor egy weboldal címét beírjuk a böngészőbe, és elküldjük a kiszolgálónak, akkor mindig először a dinamikus hívás jut érvényre. A webkiszolgáló lefuttatja a HTML tartalom generálásához szükséges kódot, adatbázisból olvas, az onnan kapott értékekkel sokszor bonyolult műveleteket végez - ez sok memória és CPU igénnyel jár.
A HTML kód eljut a böngészőhöz, amely azt feldolgozza, és a kódban lévő forráshivatkozások letöltése miatt újra a webszerverhez fordul, ami a kiszolgáló fájlrendszerén lévő statikus fájlokat sorban elküldi a böngészőnek. Amikor minden tartalom megérkezik a böngészőhöz, az oldal ezt követően fog teljes mértékben megjelenni.
Egy-egy weboldal betöltődéséhez nem ritkán 50 vagy akár sokkal több ilyen olvasási kérelem kiszolgálása szükséges.
Egy nagyobb látogatottságú weboldal normál esetben igen magas teljesítményt követel meg a webszervertől, ugyanis a látogatások mértékétől függően akár egyidőben kell fájlokat átadnia egy az egyben a böngészőknek, miközben programkódot is futtat, és adatbázisműveleteket hajt végre.
Ha a statikus webtartalom kiszolgálását egy másik kiszolgáló másik publikus címen végzi, az a nagy látogatottságú weboldalak esetében drámaian képes csökkenteni a webkiszolgáló erőforrásigényét.
Ahhoz, hogy ezt a fajta működést megoldjuk, sokan azt hiszik, hogy a weboldal kódján módosítani kell. Pedig nem.
Vannak olyan összetevői a webszervereknek, melyek bizonyos feltételek mellett képesek a HTML kódot úgy módosítani, hogy a statikus tartalmak más címre kerüljenek. Ezt követően a dinamikus kiszolgáló (D) a weboldal megnyitásakor (1) a visszaadott kódba a statikus tartalmak forráscímeit átírja a másik útvonalra (S). A böngésző a statikus tartalmakat így már más útvonalon kéri el (3) és kapja vissza (4).
Igen ám, de ha eredetileg a statikus tartalom is a fő kiszolgálón van (D), hogy kerül át a statikus kiszolgálóra (S)?
Amikor a statikus kérés befut, és az adott fájl még nincs jelen a szerveren, az automatikusan elkéri azt a fő szervertől (3a és 3b), majd helyben, memóriában tárolja, így a közeljövőben még diszkműveletre sincs szükség a tartalom kiszolgálásához, tehát itt már minden csak a hálózat sebességén múlik.
Az ilyen módon eltárolt statikus tartalmak a házirendtől függően akár több hétig is gyorsítótárazhatóak.
Azt hihetnénk, hogy egy ilyen kiépítés esetén több erőforrásra van szüksége a rendszernek, hiszen két kiszolgálót használunk egy helyett. Pedig nem, mert ha a két rendszer erőforrásait összvonnánk, és egy kiszolgálóval oldanánk meg ugyanezt a feladatot elkülönített statikus tartalomszolgáltatás nélkül, akkor az így kapott rendszer magas látogatottság mellett kevésbé bírná a terhelést.
Tehát avval, hogy két kiszolgálót használunk egy helyett, tulajdonképpen spóroltunk.