Daugelis tinklalapių pradeda nuo mažo paprasto pigaus „shared“ hostingo. Santykinai mažai vietos, jokių ypatingų sąlygų, resursų apribojimai, jokių papildomų modulių. Visi resursai yra viename serveryje - ir HTTP serveris, ir duomenų bazė. Vieną dieną jo savininkai gaus pranešimą iš talpinimo kompanijos, kad jiems laikas keltis kitur arba pirkti sau dedikuotą serverį. 
Daugelis tinklalapių pradeda nuo mažo paprasto pigaus „shared“ hostingo. Santykinai mažai vietos, jokių ypatingų sąlygų, resursų apribojimai, jokių papildomų modulių - beveik gyvenimas studentų bendrabutyje. Visi resursai yra viename serveryje - ir HTTP serveris, ir duomenų bazė. Jei tinklalapis yra populiarus, vystomas, auga lankytojų skaičius, tai vieną dieną jo savininkai gaus pranešimą iš talpinimo kompanijos, kad jiems laikas keltis kitur arba pirkti sau dedikuotą serverį. Kodėl? Didėjant lankomumui toks tinklalapis pradės reikalauti vis daugiau resursų iš serverio ir Jūsų „kaimynai“ pradės dėl to nerimauti. Vėlgi kaip bendrabutyje, jeigu jūs per ilgai užsibūsite duše, dažnai užimsite viryklę ar per garsiai klausysite muzikos, į jūsų duris ankščiau ar vėliau pasibels kaimynai (kuriems irgi reikia šių resursų) ar bendrabučio administracija (kuri bus nepatenkinta didele sąskaitą ar dar kuo nors).
Savaime aišku, kad šiuo atveju daugelis pasistengs peržiūrėti savo kodą, optimizuoti užklausas į duomenų bazę, pasinaudoti įvairiais kešavimo metodais, bet tai nebus panacėja nuo šios problemos. Anksčiau ar vėliau, beaugant lankomumui bei tinklalapio funkcionalumui jūs vėl susidursite su šia problema.
Taigi sprendžiant iš to, kad projektas auga, jis jums atneša pelną ir jūs jo atsisakyti nenorite, apsisprendžiate persikelti į naujutėlį, dedikuotą, tik jūsų projektui skirtą serverį. Jis bus įdiegtas ir sukonfigūruotas tik jūsų reikmėms, niekas kitas išskyrus jus nenaudos šio serverio resursų. Tam tikrą laiką jūs, kaip ir tūkstančiai jūsų vartotojų, būsite labai patenkinti, kaip veikia tinklalapis. Bet ar ilgam? Naujas galingas serveris - tai naujos galimybes, nauja plėtra, nauji vartotojai. Ir vėl jūs susidursite su ta pačia problema - resursų stoka. Žinoma, jūs galite nusipirkti dar vieną greitą kietąjį diską, įdėti dar kelis GB atminties ar nusipirkti galingesnį mikroprocesorių. Bet kiekvienas „geležies“ gabalas turi savo plėtros ribas. Juk persikrausčius iš bendrabučio į naują butą jūs jį būtinai apstatysite, bet iki tam tikros ribos. Tačiau Jūsų tinklalapis ir lankytojai nežino (ir nenori žinoti) apie apribojimus.
Be to čia būtinai susidursite su viena iš šių problemų - resursų stoka duomenų bazei arba resursų stoka HTTP serveriui (kadangi mes kalbame apie dinaminį tinklalapį). Kodėl?
Duomenų bazės atžvilgiu, kuo daugiau duomenų turite, tuo daugiau resursų reikia jų rūšiavimui, agregavimui, indeksavimui. Galų gale reikia resursų tiesiog jų skaitymui ir perdavimui klientams bei atnaujinimams.
HTTP serveriui reikia resursų ruošiant informaciją vartotojams, HTML puslapių generavimui (kaip pavyzdys, vienas PHP5 FastCGI procesas užima apie 25 MB atminties, norint per sekundę sugebėti aptarnauti 200 užklausų prireiks apie 2,5 GB atminties, jei atsako generavimo laikas yra 0.5 sekundės 25MB*200*0,5=2500MB, taip pat dar čia nepriskaičiuota atmintis, kurią sunaudos pats PHP skriptas vartotojo duomenims).
Atminties reikia ir pačiai operacinei sistemai, ir failų kešavimui, ir duomenų bazei (o ji irgi labai mėgsta atmintį).
Taigi jūsų tinklalapiui vėl trūksta resursų (arba jūsų butas jums tapo ankštokas ir jame netelpa naujas plazminis televizorius). Kadangi daugelis tinklalapių sudaryti iš 2 pagrindinių komponentų, dažniausiai yra perkamas dar vienas serveris ir atskiriama duomenų bazė nuo HTTP serverio (senus baldus išnešate į ką tik iš kaimyno nupirktą rūsį). Taip laimimi resursai tinklalapiui. Jei jūsų gera “geležis” ir tinklalapis skirtas Lietuvai, ir pas jus viskas gerai suplanuota (naudojamas įvairus kešavimas, normali duomenų bazės struktūra, puiki palaikymo komandą), šios struktūros užtektų. Tačiau, jeigu projektas yra populiarus naujienų portalas ar kitas jaunimui skirtas resursas - blogai, pažinčių portalai, reikia galvoti plačiau.
Pastaba: aš nekalbu apie tuos atvejus, kai informacija kartais imama realiuoju laiku iš trečių šaltinių ir tinklalapio greitis priklauso nuo jų.
Kas gi būna su tais super-populiariais projektais? Jie vėl susiduria su resursų problema. Ką jie daro? Vėl perka serverius. Tik dabar jiems svarbu padaryti viską teisingai. Šio atveju reikia labai atsargiai nustatyti, kas yra tas “kaklelis”, kuris neleidžia tinklalapiui greitai veikti ir kiek bei kokių serverių reikia.
Jei problema slypi HTTP serveryje, prireiks mažiausiai 2 naujų serverių. Viena iš jų teks sukonfigūruoti panašiai kaip turimą (arba tiesiog nuklonuoti), o iš kito padaryti apkrovimo paskirstymo serverį (angl. load balancing). Nuo šio momento apkrovimo paskirstymo serveris spręs, kuriam iš esamų HTTP serverių perduoti ateinančios HTTP užklausos aptarnavimą. Savaime aišku, kad atliekant tokius pakeitimus tinklalapio struktūroje reikia nepamiršti apie tykančius pavojus - sesijas, kešavimus, vartotojo užkraunamus failus, tinklalapio failų/skriptų sinchronizavimą - visa tai gali tekti pakeisti ar perdaryti.
Jei jums įdomu, kam reikalingas papildomas apkrovimo paskirstymo serveris, kai viską galima atlikti paprasčiausiai nukreipiant dalį vartotojų į naują serverį su kitokiu trečio lygio domenu, atsakymas paprastas - vartotojai neturi nieko pastebėti. Asmeniškai man nepatinka, kai atėjus į tinklalapį mane nukreipia tai į www1.pavyzdys.lt, tai į www5.pavyzdys.lt, o vėliau ir www256.pavyzdys.lt, aš noriu visada lankytis www.pavyzdis.lt, kaip tai darau lankydamasis www.google.com ar www.youtube.com.
Turint tokią struktūrą lengvai, bet kuriuo metu, galima pridėti naują HTTP serverį, juos sukeisti, atnaujinti niekam nieko nepastebint - tereikia nusipirkti naują serverį, jį sukonfigūruoti, pajungti ir pranešti apkrovimo paskirstymo serveriui, kad toks yra.
Nepriklausomai nuo programavimo kalbos Unix/Linux platformoje tam naudojami Lighttpd, NGINX arba Apache 2.2 serveriai (na gal yra ir kitų, bet apie jų žinomų naudojimo atvejų nesu girdėjęs). Yra įvairios konfigūracijos, kurios leidžia pasiekti įvairių rezultatų, viską galima rasti šių programinių produktų vartotojo instrukcijose. Kaip tai daroma po Windows platforma man dar nėra žinoma.
Augant HTTP serverio galimybėms vis daugiau skaitymo ir rašymo užklausų atitenka duomenų bazei. Berods iki šio momento ji buvo vienam serveryje. Didėjant užklausų kiekiui serveris gali nespėti jų patenkinti. Kaip sakė vienas žinomas MySQL specialistas - vis dėlto mus apriboja šviesos greitis.
Taigi ateis ta diena, kai prireiks kelių duomenų bazių serverių, kai tarp jų reikės sinchronizuoti duomenis. Ar tai bus paprasta konfigūracija - vienas tėvinis serveris (kur vykdomas tik duomenų rašymas) ir keli dukteriniai serveriai (kur vykdomas tik skaitymas, o duomenys sinchronizuojami replikacijos būdu), ar tai bus kažkoks sudėtingas „klasteris“ - vėl spręsit jūs, jūsų turimi resursai ir palaikymo komanda.
Mano nuomone, paprasčiausiais būdas yra būtent vienas tėvinis serveris (skirtas tik duomenų rašymui) ir keli dukteriniai, kurie yra sinchronizuojami su tėviniu serveriu ir skirti tik duomenų skaitymui (kadangi skaitymas vyksta žymiai dažniau nei rašymas).
Įgyvendinant tokius projektus reikia nepamiršti ir apie kitas galimybes bei faktorius - tinklo pralaidumą, kešavimo (kaip kliento/naršyklės pusėje, taip ir tinklalapio dalių su Memcached ar Squid) galimybes, tamsiąsias elektros dvasias. Taip pat reikėtų nepamiršti, kad kiekvienas tinklalapis yra individualus ir nėra universalių sprendimų.
Aš tyčia neparodžiau jokių konfigūravimo pavyzdžių. Juos rasite tik realioje aplinkoje, t.y. per bandymus, klaidas, bemieges naktis. Sėkmės jums auginant tinklalapius.
