Vlákno názorů k článku Hostujeme Python weby: dva i více hadů od Zdeněk - Jako python-to-python API pro rozdělení HTTPd a frameworku...
-
Zdenek (neregistrovaný)
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.
-
V článku je vysvětlené, že každá aplikace je stavěna nad moduly, které rády mění vlastnosti se zvyšujícím se číslem buildu. Proto vznikl virtualenv, který dokáže spustit aplikaci v uzavřeném pythoním prostředí.
U Pythonu je FastCGI zbytečným overheadem, protože když už spustíte nějaký pythoní FastCGI server, věřte mi, že to je jen mezivrstva k WSGI. WSGI je standardní protokol samotného Pythonu. FastCGI server postavíte téměř na čemkoli.
-
Zdeněk (neregistrovaný)
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.
