Názory k článku Hostujeme Python weby: dva i více hadů

echo "/opt/python27/lib" > /opt/python27/bin/python
ldconfig

To je nějaká blbost, ne? Nemělo by to spíš jít do /etc/ld.so.con­f.d/python.conf než přepisovat binárku pythonu?

A hned ten další odstavec začínající Podobně můžete postupovat s Pythonem 3.2 s jediným rozdílem. Místo setuptools použijte distribute: logicky patří asi tak o půl stránky dolů, až za instalaci virtualenv do 2.7.

No a odbýt WSGI ve článku o hostování webů jediným odstavcem s neurčitým odkazem do budoucna mi přijde poněkud nešťastné. Aby to povídání bylo k něčemu užitečné tak se mělo psát primárně o virtualenv a wsgi, protože to jsou ty podstatné technologie. A klidně jsme se mohli obejít bez vaty typu kde stáhnout zdrojáky Pythonu nebo jak dlouho trvá překlad na autorově stroji.

Takže si to vemte zpátky, přepracujte a přijďte na za týden. :)

Jako python-to-python API pro rozdělení HTTPd a frameworku je to asi užitečná věc, ale nechápu k čemu je to dobré když vpředu běží Apache, a ten framework je úplně bokem v jiném procesu. Co je špatného na starém dobrém FastCGI?

Nenechte se zmást slovíčkem Fast v názvu FastCGI, je to pomalý balast. WSGI je momentálně nejrychlejší rozhraní pro komunikaci webového serveru a Pythonu. A že je rychlost odezvy u webových aplikací extrémně důležitá je snad jasné.

WSGI je rychlé, protože je to smluvené vysokoúrovňové API mezi dvěma pythoními moduly. Není to IPC rozhraní a pokud ano, už nebude rychlé- protože pak to bude nutně postavené nad něčím jiným, co se bude JEŠTĚ ohýbat aby se to nakonec jako WSGI tvářilo. A každá další vrstva zpomaluje.

Jenže máte základní předpoklad že za jedním Apache běží více různých pythonů, ergo jsou to různé procesy, takže tam logicky musí být nějaké IPC, a je jedno jestli to nazveme fCGI, uWSGI, nebo "daemon mode" WSGI. To WSGI rozhraní tam bude nakonec stejně jenom přilepeno navíc. Proto nechápu proč by pythoní webová aplikace nemohla použít rovou to co je o jednu nebo dvě vrstvy dřív, a je to zhruba stejně dobře standardní.

Vím o web hostingu celkem prd, ale osobně mi jako nejlepší řešení přijde ignorovat nějaká WSGI i xCGI, a rovnou mít všude jednoduchý nativní httpd, schovaný za společnou reverzní proxy. Když se dívám na ten WSGI protokol, tak mi to přijde tězkopádný- vždyť už jenom ten ENV hash má několik desítek klíčů a hodnot, a NAVÍC komplet HTTP hlavičky, a celé se to musí inicializovat znovu a znovu pro každý request. Než tohle ten WSGI wrapper udělá, měl bych ty hlavičky velmi pravděpodobně dávno naparsované sám.

"udržet v systému pořádek i bez použití balíčků" ... tak z toho mi jde mraz po zadech! Spravny admin si ten balicek snad dokaze udelat ne? ;o)

bolo by mozne, v dalsom clanku, pokryt aj Phusion Passenger ako alternativu k mod_wsgi a spol.? Na rozdiel od mod_wsgi, dokaze spravovat beziace instancie, takze neni nutne si spravovat vlastny cluster.

Autor patrně chtěl říci, že se jedná o švýcarský nožík a ne o francouzský klíč coby univerzální řešení :)

Zdravíčko,

sice uz uplynula dlouhá doba do vydání článku, ale přesto jsem využil tyto informace při kompilaci python 2.7 na debianu, kde je python 2.6. Rozchodil jsem virtualenv, nainstaloval nějaké knihovny a pak přišlo na řadu uwsgi. Podle oficiálních stránek http://projects.unbit.it/uwsgi/wiki/Install jsem ho přes pip nenainstaloval "do pythona 2.7", ale omylem pri zapnutem virtualenvu. Pres "pip uninstall" nejde odstranit (Cannot uninstall requirement uwsgi, not installed). Google rika, ze staci jen odstranit binarku - neni to blbost?

Všiml jsem si toho později, kdy uz mám ve virtualenvu nainstalovaných dost věcí, tak to nechci řešit smazáním a znovu vytvořením.