Hruške, jabuke, jablane, čežane.

Zadnjič sva se z Almirjem, uradnim administratorjem dogberta, ujela v debato o tem, zakaj bi in zakaj ne bi bilo pametno pred Apache strežnik postaviti kakega izmed enonitnih strežnikov, npr. LigHTTPd.

Mogoče najprej povem kako sem sam spoznal asinhrone strežnike. Od Slo-Techovega administratorja Primoža sem izvedel, da za statično vsebino uporablja Boa webserver, ki je tudi eden izmed strežnikov tega tipa. Nekoliko kasneje sem tudi sam želel pospešiti Apacha na dogbertu, da bi statično vsebino, kot so npr. videi in Debian paketi, stregel strežnik tega tipa, dinamično vsebino pa bi še naprej serviral Apache. Ideja je bila sicer plemenita, moja izvedba pa (takrat) vseeno nekoliko kilava.

Pri strežbi z večimi nitmi namreč vsaka nit obdeluje eno povezavo, pri statičnih datotekah pa se obdelava posameznega zahtevka ustavi pri sistemskih klicih kot so branje in pisanje, ker se napolni buffer in mora za izvedbo celotnega klica program počakati operacijski sistem, da podatke pošlje ali sprejme. Enonitni asinhroni strežniki pa izkoriščajo dejstvo, da operacijski sistem omogoča, da se lahko ob polnem bufferju sistemski klic konča in se izvajanje programa nadaljuje. To se imenuje “non-blocking IO” ali “asynchronous IO”. S tem pravzaprav dobimo program, ki polni bufferje za vsako povezavo.

Glede na to, da je strošek ustvarjanja nove niti in upravljanje niti precej draga operacija, pri nekaj sto procesih Apache hitro postane počasen. Glede na to, da se PHP in večnitnost še vedno stojita navzkriž, je tudi poraba RAMa precej večja. In ko opaziš, da se za velike datoteke po nepotrebnem uporablja en Apache proces, ki zraven nosi še vse ostale module, ki bi jih morda potreboval, če bi šlo za dinamično vsebino, in to povsem po nepotrebnem.

Po drugi strani pa so asinhroni strežniki precej neprimerni za kakršno koli drugo delo kot je “polnjenje bufferjev”. Z vsakim procesorsko intenzivnim delom se namreč poveča zakasnitev pri obdelovanju zahtevka, zato je pametno vse procesorsko delo potisniti v ozadje. LigHTTPd ima zato dobro podporo FastCGI. Pri LigHTTPdju je tudi priporočeno, da gzip stiskanje izvaja PHP ali Python (oz. kar pač teče prek FastCGI) in ne LigHTTPd.

Glede na to, da je LigHTTPd zelo dober za “polnjenje bufferjev” oz. vhodno-izhodne operacije, mu proxyjanje zahtevkov do Apacha ni bistveno večja obremenitev, kot če bi tekel neodvisno, hkrati pa je lahko točka, kjer lahko prevzame strežbo statičnih vsebin in tako razbremenimo Apacha. Kar pa je danes najpomembneje, URL naslovi ostanejo enaki.

Comments are closed.