Jak na web v Pythonu

3.8.2007 14:45 | Přečteno: 7290× | Web | | poslední úprava: 3.8.2007 17:30

Tohle je moje odpověď na mail kamarádovi ohledně možností Pythonu na webu, třeba bude někoho zajímat taky, třeba někdo něco doplní.

---

CGI

CGI je pro web vcelku použitelné. Nevím, co to udělá s výkonem serveru, pokud bys měl hodně přístupů na ten web. Malé weby jako http://fotosoutez.cestovatel.cz/, http://promitani.cestovatel.cz/, http://www.koren.cz/kaplanovi běží jako CGI aplikace.

Výhoda CGI je v tom, že nemusím nasazovat žádnou sofistikovaný udělátor. Prostě rychle udělám skript, nastavím v Apachi ExecCGI, případně nějaký Rewrite či ScriptAlias a běží to. CGI v Pythonu (a obecně jakémkoliv skriptovacím jazyce) má nevýhodu, že se pro každý požadavek musí vytvořit nový proces a interpreter, zkompilovat skript do bytekódu a začít ho provádět. To může občas chvíli trvat.

mod_python

mod_python se to snaží vylepšit tím, že zapouzdří interpreter Pythonu do Apache. Pro jednoduché věci je to výhodné - vypadne režie nutná ke spuštění interpreteru, skript se kompiluje jenom jednou a pak se vždy vykonává. Navíc máš dokonce přístup k vnitřním proměnným Apache (což se taky občas může hodit). Největší nevýhodou mod_python vidím v tom, že aplikace běží pod oprávněním Apache, což není na produkčním serveru úplně ideální.

Pro mod_python existují různé zajímavé rozšíření (třeba publisher, který mapuje části cesty z URI na volání funkční z modulů, PythonServerPages handler - které umožňuje zapisovat do stránky kód v Pythonu podobně jako PHP a asi i spousta dalších.)

Myslím, že mod_python je vhodný zejména na drobné věci, na které neexistuje v Apachi modul - vhodné využití je třeba naprogramování autentizace proti SQL databázi, složitější přepisovací pravidla, na která mod_rewrite nestačí, nebo interakce s aplikačním serverem.

Pro reálné nasazení nám to v práci dělalo divné věci, všechno to běží uvnitř apache, různě se tam recyklovaly interpretery, takže se to hůř ladilo. Můj názor je, že mod_python je vhodný, pokud se kód vejde do cca 2 stránek na obrazovce. Tam je ještě možné uhlídat případné chyby a nenadělám moc velké škody.

FastCGI

FastCGI je IMHO slepá větev. (asi není!, viz diskuse níže) Místo obyčejného CGI skriptu se spáchá FastCGI skript, který běží dlouho a obsluhuje větší množství požadavků, které postupné dostává. Ušetří se opakované vytváření procesu, zavádění interpreteru a kompilace kódu. Výhodou je možnost použití s původním kódem pro CGI.

Aplikační servery

Nejvíce se mi teď líbí aplikační servery (možná existuje i lepší název, ale nevím o něm). Nejstarší je asi můj oblíbený Webware for Python, teď zrovna letí Django, TurboGears a CherryPy. (Můj oblíbený Cestovatel je postaven právě na W4PY.)

Co to je? Aplikační server je proces, který běží trvale (tedy měl by běžet ), přijímá požadavky a odpovídá na ně. Kde je rozdíl mezi aplikačním server a webovým serverem? Aplikační server nemusí umět a často ani neumí HTTP, ale má zase jiné přednosti.

Život požadavku

1. uživatel napíše adresu do řádku s adresou, prohlížeč se připojí k webovému serveru a pošle mu požadavek (klasické GET / HTTP/1.0)
2. webový server požadavek zpracuje, přeloží, zjistí ve své konfiguraci, že tyto adresy má speciální program (říká se mu adapter) a spustí ho.
3. Adapter se mrkne do svojí konfirace a zjistí, že aplikační server běží na adrese localhost:8080 či někde jinde, připojí se tam a pošle aplikačnímu serveru požadavek.
4. Požadavek je ve formátu aplikačního serveru, se kterým se Adapter umí domluvit, obsahuje podobné informace jako webový požadavek, jenom má jiný protokol - obvykle jednodušší.
5. aplikační server požadavek nějak obslouží a pošle adaptéru odpověď
6. adaptér opět odpověď přeloží třeba do HTML, předá to webovému serveru, který to pošle dál prohlížeči
7. prohlížeč to zobrazí a uživatel je spokojen (tedy obvykle není, ale ryze hypoteticky by mohl být ).

Proč tak složitě? (aneb výhody a nevýhody)

• Aplikační server nemusí obsluhovat pouze HTTP, často ho ani neumí. Protože se o odstínění protokolu stará adaptér, může aplikační server reagovat na různé typy požadavků, nejenom HTTP.
• Jeden adaptér může přistupovat na více aplikačních serverů (load balancing) a/nebo více adaptérů (webových serverů) může sdílet jeden aplikační server.
• Největší výhodou aplikačního serveru je to, že jde o dlouhoběžící proces. Může tedy mít předem připravené drahé zdroje (spojení do databáze, předpřipravené objekty sestavené z databázových data). Může i jednoduše v paměti cachovat často používaná data, apod. Oproti aplikacím typu spusť, spočítej a zahoď (PHP či CGI skripty) tím ušetří nějakou nemalou režii.
• Protože jde o samostatný proces, může běžet pod jiným oprávněním než je webserver.
• V rámci jednoho procesu je jednoduší řešit třeba plánování periodicky spouštěných úloh, dlouho běžící úlohy, komunikaci mezi různými komponentami aplikace, apod.
• Největší nevýhodou aplikační serveru je to, že jde o dlouho běžící proces - ne na každém hostingu člověku takové aplikace nechají.
• Problémem může být paměťová náročnost - čím více věcí do aplikačního serveru natáhneme, tím více paměti si pochopitelně ukousne (není problém sežrat 100 i 200MB).
• Nevýhodou může být i netriviální konfigurace a nasazení celého tohohle cirkusu.
• Komunikace mezi adaptérem a aplikačním serverem nějakou dobu trvá, obvykle však čas takto proflákaný program hravě nadežene tím, že má nacachováno.

Pro úplnost

Existuje spousta dalších přístupů pro řešení webu v Pythonu, třeba Zope, Maki, WSGI a spousta dalších. S těmi jsem ale nepřišel do styku na dost dlouhou dobu.

A co používám já?

Pro jednoduché aplikace, kdy se nezpracovávají velké objemy dat z databáze používám CGI skripty, pro aplikace, kde se stránka sestavuje z mnoha tabulek z databáze používám W4PY a důsledně cachuju (v době, když jsem začínal programovat nic jiného nebylo). Pro generování stránek používám Cheetah, ať už v CGI, tak i W4PY.

Líbí se mi Django, ale ještě jsem nenašel dost času ho prozkoumat, přecejen mne weby neživí.

       

Komentáře

[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