Pénteken megnéztük az Eredet (Inception) c. filmet, kifejezetten tetszett, na nem mondom, hogy szuper váratlan volt minden fordulat, de akkor is, jó volt. Nézze meg, aki teheti.
Csykin nemrég megszerezte a django.hu domaint, kicsit fel szeretnénk hypeolni itthon is a djangót, illetve a pythont, úgyhogy a szakmaibb postjaim ezután inkább oda mennek, itt is az első komolyabb hangvételű, a singletonokról.
Ha már megcsináltam, hogy tornado működjön rendesen Solarison is, akkor gondoltam meg is mérem, hogy mennyire rendes az - de legalábbis összehasonlítom az általunk használt hagyományos fascgi megoldással.
Igazából a tornadot nem WSGI appok futtatására találták ki, de azt is tudja, és hát egy tipikus python webalkalmazás belehelyezhető (jó esetben) egy WSGI konténerbe, úgyhogy miért ne. A tesztalkalmazás egy nagyon alap Django project lett, amiben nincs semmi, csak amit a django-admin.py startproject legyárt, illetve egy extra view, ami kiírja ügyesen, hogy Hello World!.
Hat féle felállást hasonlítottam össze, minden előtt volt egy nginx, azért is mert a cucc egy zónában futott, illetve mert a fastcgi-ket nem tudom közvetlen megszólítani "böngészővel":
A mérést az előzőhöz hasonlóan az apache féle ab programmal végeztem, a 1, 10, 100, 1000, 5000 és 10000 párhuzamos klienst szimulálva, az utolsó esetben összesen 50000, egyébként 10000 lekéréssel. Az áteresztő képességen kívül (request/sec) felírtam a kliensek 50/95/99/100%-ának kiszolgálási idejét (milisec). Utóbbi adatokból inkább nem rajzoltam grafikont 
Az előzőhöz hasonló módon a teszt egy x86-os Solaris 10-on futott - nem ugyanazon a gépen -, és ugyanúgy minden tesztet háromszor futtattam le, a legjobb eredményt feljegyezve.
Grafikon az áteresztőképességekről:
Konklúzió: a tornado bizony jóval hatékonyabb, mint a sima fastcgik, pláne, ha egy többmagos/többprocesszoros gépen a processzormagok számának megfelelő mennyiségűt indítunk (...reméljük a GIL-től majd megszabadul a python, és akkor ki lehet használni a szálakat rendesen...). Ahogy látszik viszont a _Select alapú ioloopnak meg vannak a korlátai, ha valahol ezt vagyunk kénytelenek használni, ott nginx oldalon tudunk korlátozni, hogy ne kapjon egyszerre mondjuk ezernél több kérést.
Bár a haproxy gyengébben szerepelt, mint az nginx magában, az azért lehet, mert Solaris 10-en még nem támogatja az event ports féle pollingot, csak a régebbi /dev/poll féle megoldást - ennek ellenére jól teljesít, linux alatt valószínűleg ő nyert volna.
A lényeg, hogy a tornado úgy fest valóban képes megbirkózni a tízezer kliens problémájával, és django alkalmazások alatt is jól használható, ha sok klienst kell kiszolgálni.
A nyers számok, ha valakit érdekel: tovább...
A nemrég látott előadás kapcsán felmerült bennem, hogy ki kéne próbálni, hogyan lehet adatbázist replikálni. Mert olyat még nem csináltam, legalábbis eddig.
Mire is lehet ez jó? Először is biztonságos, ha kiesik egy gép, akkor sincs nagy katasztrófa, mert van másik, ami ráadásul eléggé up-to-date. Ami viszont szintén nem elhanyagolható dolog, az a terheléselosztás, azaz van pl. egy master replikánk, amibe mennek a módosítások (INSERT, DELETE, UPDATE), és van több slave egységünk, amiket lehet kérdezgetni (SELECT). Egy tipikus alkalmazás esetében a kérdezgetések száma nagyságrendekkel nagyobb ugyebár.
Na lássuk, hogy megy a dolog, ha postgresql szervert szeretnénk használni: tovább...
Mármint én nem, sőt, de Cal Henderson, a Flikr vezető fejlesztője ezzel a címmel tartott egy előadást a nemrég zajott DjangoCon konferencián. Nem rövid, most volt csak időm megnézni, de érdemes volt, nagyon tetszik a srác stílusa.
A mondanivaló szintén nem butaság, bár egyelőre nekem - eddig még - nem volt szükségem nagyonnagy adatbázisok kezelésére.
A kulcsprobéma azonban - hogy a Djangónak nincs kabalaállata - megoldódott azóta:
Stabil API - ami azt jelenti, hogy az 1.0-s Django alkalmazások változtatás nélkül fognak futni a többi 1.x kiadáson -, és eltűnt a figyelmeztetés is, hogy nem ajánlják éles használatra. Rengeteg új feature (nem csak az előző 0.96-os változathoz képest, csak az elmúlt másfél hónapban több jelentős változás került bele a kódba), megújult dokumentáció, és a már megismert sebesség és stabilitás.
Aki webet fejleszt, nem zárkózik el az új dolgoktól, és még nem próbálta volna ki, annak mindenképpen ajánlom.
Egyik futo projectben felmerult, hogy hogy osztunk meg weben tartalmat ugy a neppel, hogy rendes access controlunk lehessen. Azaz pl. lehessen alligatni userenkent savszelesseget, hozzaferesi idot, es minden butasagot, ami csak eszunkbe jut.
Alapbol ugye van a webszerver oldali .htaccess es baratai megoldas, ahol eleg szukosek a lehetosegek, es hat nem is egy olyan kifinomult admin feluletunk van, mint a djangonak. De kigondoltam valamit, igaz a modszer nem tul hatekony - az eroforrasok szempontjabol -, de mindent lehet, amit mi akarunk, es majd max kap a gep +10% procit es memoriat.
Az alapotlet az, hogy nem kozvetlen a webszerver adja vissza a filet a kliensnek, hanem az csak egy cgi/fcgi scripttol keri azt el, ami szepen "felolvassa" azt a merevlemezrol, felteve, hogy a felhasznalonak ezt mi megengedtuk.
Ezt egyebkent egy akarmilyen scriptnyelvben nevetsegesen egyszeru megcsinalni, pl. phpban:
$filename = "/ez/a/file/kell"; header('Content-Type: ilyentipusuafile'); header('Content-Length: afilehossza'); readfile($filename);
Szoval egyatalan nem bonyolult.
Djangoban azonban nem talaltam olyat, hogyan adok vissza nem tipikus tartalmat. Az alap HttpResponse-t nem arra talaltak ki, hogy szepen olvassa fel a fileokat a winyorol, ugyhogy - eljen az OOP - leszarmaztattam belole, es ime az eredmeny.
Djangoban ezutan csak egy view kell, ami ellenorzi, hogy megfelelo-e minden feltetel (be van-e lepve a felhasznalo, a megadott idopontban tolthet-e le, kek-e a szeme, es hithu kereszteny-e), es ha igen, akkor egy egyszeru return HttpFileResponse(fileneve), es a file mar uton is van.
Nincs meg kesz persze, de akinek kell, az vigye, akinek meg van valami jo otlete, az szoljon! (A kod egyebkent a kb. 3 hettel ezelotti svn trunk alapjan keszult, stabil 0.96-os djangoval, vagy a legfrissebb fejlszetoi anyaggal nem feltetlen mukodik, de sokat tuti nem kell rajta dolgozni, hogy menjen.)
Csykinnek fejlesztettem nemreg egy szoftvert (lenyegtelen mit csinal), python alapu, es mysql-t hasznal az adatok tarolasara. Termeszetesen az alkalmazas egyetlen DBHandler nevu osztalyon keresztul kapcsolodik az adatbazishoz, aminek egy leszarmaztatott osztalya a MysqlDBHandler, igy egy sor modositasaval (es egy uj adatbaziskezelo osztaly hozzaadasaval) barmilyen mas adatbazis is hasznalhato lenne. De ebben nincs semmi kulonos, ezt minimum igy illik csinalni.
Viszont a mysql adatbazist ha a valaki az alkalmazason kivulrol szeretne piszkalni, akkor mar nincs olyan jo dolga, vagy parancssorozik, phpmysqladminozik, esetleg ir hozza valami feluletet, amin keresztul nezegetheti. Ellenben eszembe jutott, hogy mi lenne, ha az adatok tarolasara a djangot kernem meg - ezesetben a generalt admin feluleten keresztul egyszeruen elerhetem az adatokat, sot szep webes statisztikakat is eleg egyszeruen tudok utana csinalni. Ugyhogy nekialltam... tovább...
Ez egy blog. A velemenyunk a mienk, ezert szubjektiv, es meglehet, hogy neha csak picit fedi az egyetemes igazsagot. Mellesleg akinek nem tetszik, az nezze helyette a tvt.
Egyebkent nyugodtan lehet idezni, kepeket toltogetni, szabadok vagyunk.
Ha esetleg valami szemelyes kozolnivalod van, amit nem szeretnel kommentbe leirni, akkor tobbek kozott elerhetsz minket a [akiacikketirta] kukac horak pont hu emailcimen.