~hruske Hruške, jabuke, jablane, čežane. » 2007 » April
Home Contact Sitemap

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

Ste se gdaj vprašali, zakaj Najboljšega soseda nikoli ni doma, ko pridete na obisk?

LigHTTPd vs. Apache

Posted on April 28th, 2007 in dovhcajt, linux |

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.

Komentarji so izklopljeni

Django in FastCGI

Posted on April 27th, 2007 in django, linux, python |

Ko folk razmišlja o skupnem gostovanju, je včasih težko obiti dejstvo, da je Python razmeroma požrešen, kar se tiče porabe RAM-a. Na Webfactionu je en ukaz, s katerim lahko izračunamo, koliko RAMa posamezen program uporablja. Sam sem jo nekoliko spremenil, da prikazuje samo Python:

ps -u username -o pid,rss,command | grep -v awk | \\
  awk '/python/ {print $0 ; sum+=$2} END {print "Total", sum}'

Django lahko prek FastCGI poganjamo na dva načina, z večimi nitmi in z večimi procesi. Če ga poganjamo z večimi procesi (prefork), je izpis zgornjega ukaza sledeč:

 6646  4320 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
 6647  3788 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
 6648  3800 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
 6649  9604 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
 6650  9608 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
 6651  8512 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
Total 39632

Če ga poganjamo večnitno (threaded) pa sledeč:

 6747 10236 python prevoz/manage.py runfcgi method=threaded host=127.0.0.1 port=34001
Total 10236

Pri tem gre omeniti, da sem pred merjenjem trikrat pognal ukaz httrack 127.0.0.1 -c10, ki prezrcali celotno stran, projekt, ki sem ga uporabil za testiranje, pa je bil razmeroma enostaven. Django pa je bil na FastCGI priklenjen prek flup r2347 in LigHTTPd spletnega strežnika.

Z večnitnim načinom lahko tako prihranimo precej RAM-a, velja pa omeniti, da Python v osnovi ni večniten in se bo pravzaprav naenkrat obravnaval le en zahtevek, čeprav bo vmes prihajalo do preklopov med nitmi.

Komentarji so izklopljeni

NFS prek IPv6

Posted on April 24th, 2007 in debian, linux |

Še ena dobra IPv6 novica. Z Linux kernelom 2.6.21 bo NFS v jedru dobil podporo za IPv6, kar v praksi pomeni, da NFS do Kiberpipe od doma ne bo več tako neverjetna stvar.

;)

Komentarji so izklopljeni

Kako do IPv6 povezljivosti v Debianu ali Ubuntu

Posted on April 22nd, 2007 in debian, linux |

Vista je tu in ima privzeto vklopljeno podporo za IPv6, zato ni več razloga, da si ne bi pobliže pogledali kako vašo Visto (ali pa XP), ki je skrita za enim Linux firewallom oz. routerjem, prek IPv6 predstavite širnemu svetu. Izkaže se, da je to precej enostavno.

Najprej moramo poskrbeti, da dovolimo IPv6 promet na požarnem zidu.

iptables -I INPUT -p ipv6 -j ACCEPT
iptables -I FORWARD -p ipv6 -j ACCEPT

Potem postavite tunel, ki bo služil za dostop do IPv6 routerja. Namesto JAVNI_IP morate vpisati vaš trenutni javni IPv4 naslov.

ip tunnel add tun6to4 mode sit ttl 80 remote any local JAVNI_IP
ip link set dev tun6to4 up

IPv4 naslovi so vsebovani v IPv6, tako da vsakemu javnemu IPv4 naslovu pripada ustrezno omrežje IPv6 naslovov, ki so skriti za tistim omrežjem. Ker IPv6 uporablja hex notacijo, je potrebno IPv4 pretvorit v hex. Če je vaš javni IPv4 npr. 195.37.65.121, potem to pretvorite v hex tako:

$ printf "%02x%02x:%02x%02x\n" 195 37 65 121
c325:4179

Vrednost, ki jo je vrnil prejšnji ukaz, potem vključite v IPv6 naslov:

ip -6 addr add 2002:c325:4179::1/16 dev tun6to4
ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1

Sedaj bi morali imeti IPv6 povezljivost in bi vam moral ukaz “ping6 -c 4 ftp.hr.debian.org” pokazati nekaj spodnjemu podobnega:

$ ping6 -c 4 ftp.hr.debian.org
PING ftp.hr.debian.org(debian6n.CARNet.hr) 56 data bytes
64 bytes from debian6n.CARNet.hr: icmp_seq=1 ttl=52 time=63.0 ms
64 bytes from debian6n.CARNet.hr: icmp_seq=2 ttl=52 time=62.3 ms
64 bytes from debian6n.CARNet.hr: icmp_seq=3 ttl=52 time=62.4 ms
64 bytes from debian6n.CARNet.hr: icmp_seq=4 ttl=52 time=62.4 ms

--- ftp.hr.debian.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3011ms
rtt min/avg/max/mdev = 62.398/62.560/63.006/0.358 ms

Če ste IPv6 usposobili na routerju in bi želeli tudi ostalim napravam, ki so bile do sedaj skrite za routerjem, dodeliti javne IPv6 naslove, potrebujete še t.i. “route advertisement daemon” oz. program, ki oznanja naslov omrežja. Eden enostavnih je radvd.

Vse kar potrebujete nastaviti, je datoteka /etc/radvd.conf. Primer je spodaj, pri tem je eth0 omrežni vmesnik, na katerem imate notranje omrežje, c325:4179 pa je IPv4 naslov, ki smo ga zgoraj prekodirali v hex notacijo.

interface eth0
{
   AdvSendAdvert on;
   MaxRtrAdvInterval 30;

   prefix 2002:c325:4179:1111::/64
   {
       AdvOnLink on;
       AdvAutonomous on;
       AdvRouterAddr on;

   };

};

Veselo pinganje.

Komentarji so izklopljeni

“Pyton” in “Just Plone it”

Posted on April 19th, 2007 in dovhcajt, linux, python |

Zavod aktivnega izobraževanja (nedaleč od Kiberpipe) prireja serijo tečajev za začetnike, s pomočjo katerih se boste priučili Linuxa, Pythona, Plone-a. Lepo je videti, da ni samo Kiberpipa tista, ki se trudi širiti odprtokodno zavest.

Stvar je brezplačna, je pa obvezna prijava na info(a)aktivno.si.

Pogrešam zgolj kako dodatno informacijo, npr. kdo predava, morda pa tudi ne bi škodilo “pyton”-a pisati kot “python”.

Komentarji so izklopljeni