Jak na web v Pythonu (diskuse)

[Vašek Lorenc]

Docela hezké shrnutí, ale fastCGI není zase tak špatná věc.. právě kvůli možnosti pouštět ho pod svým uid, narozdíl od mod_python.

[Věroš]

Jo, to máš pravdu, to mi nedošlo, protože ho nepoužívám. Ale CGI je taky možné při troše dobré vůle setuid()ovat.

[happy barney]

fast_cgi môže navyše bežať aj na inom (a nie len jednom) stroji. setuid CGI však nemá výhody fastcgi. Btw, fast_cgi je podľa popisu v tomto blogu "aplikačný server".

[Vašek Lorenc]

Jak už tu psali jiní, ono to není jen o tom setuid(). Já s tím například urychlil běh jednoho pythonovského webového wiki+blog projektu, který veškeré HTTP požadavky tlačil přes sebe.. v původním CGI prostředí to bylo naprosto nepoužitelné (zvlášť na naší studentské aise, které spuštění jednoho python procesu trvá skoro vteřinu). FastCGI sice vyžadovalo drobné úsilí na přepsání, ale od té doby mi stránky jedou alespoň trochu použitelně..

Paralelní požadavky to zpracovávat umí (záleží na tom, jak je napsaný ten pythonovský program), navíc (opět už někde zmíněno níže) to není závislé na Apachi.

Ale fakt se mi to shrnutí líbilo.. Ještě pár příspěvků, uděláš novou revizi.. a bude z toho pěkné mini-howto :)

[Věroš]

Fajn, a kdo zpracuje tu sekci o FastCGI a kdo se zmíní o WSGI? K tomu jsem se naživo taky nedostal.

[Radek Podgorny]

FCGI slepa vetev? To snad ne... Nepouzivam nic jineho...

Treba kdyz clovek nechce pouzivat apache, je mod_python ze hry. CGI je prilis pomale/hloupe (pokazde init, nedrzi stav, ...). Takze pro mne z toho vychazi FCGI jako vitez.

...pravda, apl. servery jsem jeste neprozkoumaval, ale na druhou stranu mi reseni webserver+fcgi vzdy stacilo...

[Věroš]

Beru zpátky tvrzení, že FastCGI je slepá větev. Nezkoušel jsem ho osobně, jen jsem letmo četl návod (já vím, tak to dopadá, když člověk píše o něčem, co nemá osahané).

Umí FastCGI obsluhovat více paralelních požadavků?

[Pavel 'lingeek' Szalbot]

FastCGI je protokol. Tudíž tvoje otázka je podobná otázce, zda HTTP umí obsluhovat více paralelních požadavků. Mrkni třeba na flup.

[andree]

vzhladom na to, ze napr. aj lighttpd pouziva fastcgi (napr. aj pre php), a je pritom rychlejsi/menej-nenazrany ako apache (jedno z googleovanych porovnani), tak asi fakt nebude az tak dead... a kedze sa to pouziva na to php, tak to asi snad bude zvladat aj paralelne poziadavky (ale to len tipujem, dokaz v ruke nemam, netestoval som to) :)

[happy barney]

fastcgi je sekvenčné. paralelizmus (http požiadaviek) sa rieši viacnásobným spustením daemona a tým, že o http réžiu sa stará iný proces (a teda miesto čakania na pomalého klienta sa môže venovať ďaľšej úlohe).

[andree]

myslel som si :)

[Věroš]

V tom případě ale u FastCGI ztrácíme výhodu jednoduché synchronizace dat pro více požadavků, ne?

Zkusím popsat situaci, kterou mám a rád bych se zeptal, jak se řeší s FastCGI?

u portálu s větší návštěvností (pěkně to popsané v starším Leošově článku) je výhodné držet si v cache věci, které jsem už načetl z databáze - ušetřím tím čas, který normálně strávím balením řádků z databáze (např.článků) do objektů. Do objektů je balím proto, že se s nimi potom dobře pracuje - třeba v šablonovacím systému. Při případné změně řádku v DB (editace článku) potom elegantně vysypu tu část cache, která je dotčená a běžím dál.

Chápu, že pokud mám aplikaci v jednom procesu, který se dělí na více vláken, můžu cache jednoduše vysypat na jednom místě.

Oproti tomu, pokud mám více procesů, musím všem procesům dát na vědomí, že se vysypat cache, což je velmi netriviální na implementaci (blbě se to programuje, blbě se to ladí, nevím kolik těch procesů je a tak).

Více paralelních požadavků potřebuju, protože od určité návštěvnosti už jedna fronta požadavky obsluhovat stíhat nebude.

---

Uvítám i myšlenky na efektivnější řešení

Memcached jsem zkoumal, ale nevěřím tomu, že picklovat a unpicklovat složité Pythonové objekty bude stejně rychlé jako držet je v paměti.

Vím, že od další určité hranice stejně budu potřebovat stejně více procesů - GIL je docela potvora, a synchronizaci mezi více procesy, ne-li počítači se nevyhnu. (POSH je zajímavá věc a nakonec i ten memcached pro synchronizaci mezi více počítači jsem ochoten vzít na milost).

[Pavel 'lingeek' Szalbot]

Chápu, že pokud mám aplikaci v jednom procesu, který se dělí na více vláken, můžu cache jednoduše vysypat na jednom místě.

Oproti tomu, pokud mám více procesů, musím všem procesům dát na vědomí, že se vysypat cache, což je velmi netriviální na implementaci (blbě se to programuje, blbě se to ladí, nevím kolik těch procesů je a tak).

Opravdu si myslíš, že vysypat cache sdílenou více vlákny je bez synchronizace košér? To je ovšem velmi naivní představa.

Více paralelních požadavků potřebuju, protože od určité návštěvnosti už jedna fronta požadavky obsluhovat stíhat nebude.

Jedná blokující fronta ti nebude stačit velmi brzy.

Od určité návštěvnosti budeš potřebovat více web serverů. Vertikálně škálovat nelze donekonečna.

Memcached jsem zkoumal, ale nevěřím tomu, že picklovat a unpicklovat složité Pythonové objekty bude stejně rychlé jako držet je v paměti.

Memcached určitě nebude nic picklovat. To bude dělat Python a pokud myslíš, že pomalu, pak zkus jiný jazyk, nebo ukládej objekty jiným (lepším) způsobem.

[Věroš]

Už se asi se bavíme každý o něčem jiném. Mě by zajímalo hlavně jak (lehce) se řeší ve FastCGI věci se sdílením dat mezi více procesy.

Opravdu si myslíš, že vysypat cache sdílenou více vlákny je bez synchronizace košér? To je ovšem velmi naivní představa.

Když cache má GET, PUT i FLUSH implementované atomicky, tak by neměl být problém. Pletu se? Oproti tomu udělat synchronizaci v cache mezi více procesy je IMHO řádově složitější. Memcached by to teoreticky řešil.

Memcached určitě nebude nic picklovat. To bude dělat Python a pokud myslíš, že pomalu, pak zkus jiný jazyk, nebo ukládej objekty jiným (lepším) způsobem.

Picklovat bude Python, ale nedokážu si představit, jestli režie picklování nebude větší než natahování z databáze. Objekty, které teď držím v cache jsou poměrně složité. Jediný způsob, jak to zjistit je to vyzkoušet. (zkusím a napíšu). Jestli existuje něco pohodlnějšího, tak se rád nechám poučit.

Nenašel jsem zatím jazyk, který by mně osobně vyhovoval více než Python. A že jsem se snažil. (no flame please ).

Od určité návštěvnosti budeš potřebovat více web serverů. Vertikálně škálovat nelze donekonečna.

Že časem budu potřebovat víc webserverů je mi už teď naprosto jasný, zatím naštěstí mám dost času, myslím, že ještě rok mi ještě bude stačit posilovat hardware

[Pavel 'lingeek' Szalbot]

Ty totiž pleteš dohromady FastCGI a memcached. Tedy co se memcached týče - skutečně se chová atomicky, jak popisuješ a problém bys neměl. K (de)serializaci objektů - nedovedu si představit, že bys cachoval a serializoval něco, co bude rychlejší načíst z databáze.

Nejdříve začni pracovat, vypusť první verzi mezi lidi, počkej měsíc, dva, tři a pak stejně zjistíš, že potřebuješ řešit úplně jiné problémy, než sis myslel a mohl jsi tak mít aplikaci funkční o pár týdnů dříve. Pokud tedy smím vycházet z toho, že jeden server (časem maximálně oddělení DB) a optimalizace ti pár měsíců vystačí.

[happy barney]

FastCGI to nerieši, necháva to na aplikácii. Jednoduchý dôvod: neexistuje univerzálne riešenie (to si len pár OOP-istov vysnívalo).

IMHO, lepšie ako zdielaná cache je prekopanie aplikácie, človek sa môže dostať do situácie, keď mu na CRUD jednotlivých entít bude postačovať jeden subdaemon a výsledok bude skladať druhým(tretím, ..) stupňom.

[Jardík]

Nejlepší je si web napsat v C, to pak nepotřebujete žádný interpret

[noname265]

Nejlepší je napsat si web v Assembleru...pak na to nepotřebuješ ani GCC nebo jiný překladač ;)

[Luboš Doležel (Doli)]

No, pokud to neplánuju psát přímo v hexeditoru, tak asi přece jen nějaký překladač potřeba bude.

[noname265]

ja bych to psal primo v binarnim kodu

[Věroš]

Ne, přátelé - jste úplně mimo. Nejlepší je nemít web. Vím o čem mluvím, jeden web mám, a furt chodí mi tam lidi.

Zkuste se prosím držet tématu, předem děkuju.

[David Jaša]

Počkejte, počkejte, pomalu. Na takový návaly nejsme zařízený.

Počkejte prosím, až si stránku prohlédne předchozí návštěvník.

[botanicus]

Nejlepsi je napsat tu informaci na papir, ten je vzdycky kompatibilni, nepotrebuje ani gcc natoz interpret ;)

[Daniel Kvasnička ml.]

No u mod_pythonu bych se vic rozepsal o moznosti a principu psani vlastniho handleru. Je to precijen to nejzajimavejsi, co mod_python nabizi Ale jinak hezky.

[Ivanhoej]

Pouzival som roky Zope, no nie len koli dost narocnej sprave, ale i koli narocnosti na pamat som ho nahradil inym riesenim. Chcem sa opytat ako je na tom Webware for Python s obsadenim pamate a vytazenim CPU? Hlavne ide o tu pamat.

Mne stale vrta hlavou RoR, len keby bol cas to poriadne skusit :(. Ma niekto skusenost ako je to u RoR s pamatou.


Vdaka.

[Věroš]

W4PY je úplně řešení úplně jiného problému než Zope. Jediné, co mají společné je že jsou v Pythonu a že jsou i pro web.

Ve srovnání s Djangem, TurboGears či RoR je W4PY poměrně low-level řešení - což má svoje nevýhody (některou práci člověk musí udělat sám), ale i výhody (nes..e se mi pod ruce nějaký toolkit a nemusím obcházet jeho způsob myšlení; vím, co jsem naprogramoval).

W4PY je v podstatě tupý servlet container (cca odpovídá Tomcatu). Já ho používám proto, že když jsem začínal na webu, moc podobných nástrojů k dispozici nebylo.

Django osobně neznám. Čekal bych, že pro malé aplikace bude výhodnější Django (rychlejší počáteční vývoj), a před naprogramováním velké aplikace si člověk udělá analýzu, co vlastně potřebuje za prostředí a podle toho si vybere.

W4PY a zabraná paměť: mám aplikace, které sežerou 10MB a mám jednu, která sežere 200MB - co si člověk naprogramuje, to má. Teď zrovna má 120MB a v paměti mám se drží asi 3500 objektů + dalších 400 jednoduchých struktur (většinou n-tice o několika jednoduchých).

[Pev]

Diky Věroši :).

Pev