Ako som už písal, WSGI posúva možnosti hostovania Python aplikácii o míľové kroky dopredu. U WSGI je však jedna zrada, ktorá môže spôsobiť, že vaša aplikácia má namiesto dramaticky vysokého výkonu, výkon dramaticky mizerný.
Problém je v tom, že väčšina tutoriálov vám odporúča nainštalovať WSGI a spraviť drobnú konfigurácie. Tradá a aplikácia funguje.
Lenže!
Ide relatívne rýchlo a ešte rýchlejšie vám zožiera pamäť. Pri vysokej záťaži odvarí server na load 55 a podobné radosti. V čom je problém? Neprečítali ste si manuál.
Autori WSGI už asi boli znechutený tým, ako na nich ľudia neustále frflú a upozornenie pre používateľa dali na prvú stránku projektu. Niečo na štýl: nesušte zápalky v mikrovlnke.
Problém je v tom, že v základnom móde beží WSGI ako embeded aplikácia. Čo je tak dobré na malé jednoduché aplikácie typu Ahoj Mexiko. Pokiaľ teda nie ste expertom na tunenie Apacha, je pre vás vhodnejší mód, kedy beží aplikácia v démon procese.
Čo na to treba? Vlastne pridať len dva riadky do konfigurácie VirtualHostu:
WSGIDaemonProcess georgik.sinusgear.com threads=15 maximum-requests=10000 WSGIProcessGroup georgik.sinusgear.com
Úžasné! Rozdiel, ktorý vidíte, aj cítite 
Update: Rozhodne si prečítajte komentár od Messa. Veľmi dobre vysvetľuje princíp fungovania Apache/Python.
Október 22nd, 2009 at 12:22
[...] článek: Georgik // WSGI mizerný výkon? Čo tak prečítať manuál? [...]
Október 22nd, 2009 at 13:24
A nebo čo tak zapomenout na Apache?
Pak se člověk nesnaží vše mrzačit pro Apache, protože se to tak kdysi naučil…
Október 22nd, 2009 at 13:32
Keby to šlo, tak by to bolo pekné. Každopádne Apache rieši veľa vecí, od load balancingu, cez proxy rules, až po SSL frontend. Obávam sa, že ani jediný Pythónsky framework ho nedokáže zastúpiť.
Október 22nd, 2009 at 17:52
Pythonové frameworky ani nejsou určeny k tomu, aby uměly load balancing, proxy rules atd., protože se předpokládá, že budou až za front-end webserverem (Lighttpd, nginx, Apache…), které právě toto umějí. Ani by pak na jedné IP adrese nešlo provozovat víc aplikací
Jde mi o to, že typické přemýšlení taky-admina serveru je “mám Apache, chci jazyk XXX, tak to si musím nainstalovat mod_XXX.” (Naštěstí už je mod_wsgi populárnější než mod_python.) Ale už se nezamyslí nad tím, jak Apache funguje, že po akceptnutí spojení v child procesu se prostě ta WSGI aplikace v tom procesu bude muset spustit (pokud už neběží), a že za pár minut/hodin těch instancí bude aspoň tolik kolik je child procesů, protože narozdíl od PHP se tyto instance po zpracování požadavku neukončí. A těch child procesů je jak malých myší.
To samé pro každou další takto nasazenou aplikaci – v každém child procesu Apache bude nakonec běžet od každé aplikace jedna instance, přitom je jasné, že v jednom konkrétním čase je využita jen jedna z nich a ty ostatní jen zabírají paměť a čekají na ten správný “jejich” request. A to zde ještě neřeším oprávnění (aby si uživatelé/klienti navzájem nesahali na soubory), to možná ani vyřešit nelze.
Ale hlavně, že admin nainstaloval mod_něco, vždyť to přeci musí běžet, tak to dělají všichni, ne? Ano, i některé webhostingy používají mod_python, ale jen s nechutí a jen u nejdražších tarifů, proč asi
Systémovým řešením je právě proxování, nebo daemon mód mod_wsgi, což je jen proxování s jiným protokolem. Dokonce za “front-end” web serverem lze spustit dalšího Apache dedikovaného jen pro danou aplikaci, ale to už je lepší spustit HTTP server rovnou v Pythonu (pro produkční nasazení třeba CherryPyWSGIServer, pro vývoj jakýkoliv, třeba ten z wsgiref). Prosím, nemyslete Apache-centricky – nainstalovat mod_něco podle tutorialu občas nestačí, je nutné se zamyslet (když to neudělal autor tutorialu)
Omlouvám se za dlouhý komentář, ale doufám, že jsem aspoň některému čtenáři trochu vyjasnil situaci.
Október 22nd, 2009 at 18:16
Vynikajuci komentar! Dakujem!
Toto by si mali precitat vsetci admini a developeri tiez.