[Python] web: sync vs. async

[Roberto De Ioris]

> On Sat, 03 Dec 2011 15:51:08 +0100, Manlio Perillo wrote:
>> Il 02/12/2011 23:25, Daniele Varrazzo ha scritto:
> [tante cose]
>
>
>
> Tra l'altro, nel confronto di sopra, uno dei deploy più performanti è
> risultato uWSGI di Unbit (complimenti!), che usa proprio un modulo C in
> un web server esterno. Nell'articolo viene presentato come soluzione
> processor/thread, ma ricordo che l'anno scorso stavano facendo
> esperimenti coi greenlet. È possibile usare Nginx + uWSGI per servire un
> applicativo wsgi servendo richeste multiple per processo via greenlet?
>
> Ne vale la pena o non ci si guadagna molto rispetto ad usare i thread?


Quel benchmark non e' proprio affidabilissimo (a parte che e' bello
vecchiotto) in particolare non rende giustizia ad apache+mod_wsgi in
quanto chi ha fatto il benchmark non lo ha certo configurato per competere
alla pari con uWSGI o gevent. Ovviamente a me va bene cosi' :P

Per quanto riguarda uWSGI ha il supporto "asincrono" da un paio d'anni
(tra l'altro lo scrissi proprio per usare psycopg2/psycogreen)

http://projects.unbit.it/uwsgi/wiki/AsyncSupport

a cui poi si e' aggiunto subito dopo un motore co-routine indipendente dal
linguaggio:

http://projects.unbit.it/uwsgi/wiki/uGreen

rispetto a greenlet era (ed e') piu' veloce ma occupa un fottio di memoria
in piu' (prealloca tutti gli stack)

Da un annetto uGreen puo' essere sostituito sia da greenlet che da
stackless python in modo trasparente (rimane quindi la stessa funzione
uwsgi.suspend()).

Qualcuno si e' gasato pensando che questo bastasse a supportare gevent
(con tanto di annunci eclatanti su hackernews), ma in realta' non
funzionava una cippa...

Quindi qualche mese fa e' nato questo:

http://projects.unbit.it/uwsgi/wiki/Gevent

che sebbene funzioni egregiamente consuma piu' memoria di
uwsgi_async+ugreen (boh)

Se leggi il disclaimer del primo link, capirai bene come la penso su
questo stile di programmazione, e presumo che Manlio la pensi ugualmente
ecco perche' consiglia un approccio piu' semplice (e io oserei dire anche
"robusto"). Se non si ha bisogno di scalare a livelli inumani, non serve a
niente andare a cambiare tutta la logica di sviluppo. I thread di python
saranno "castrati" dal GIL ma il loro scopo e' aggiungere concorrenza, le
performance diventano secondarie.
Se si vuole sfruttare l'SMP basta andare di preforking+threads (o solo
preforking che va bene nel 99.999% dei casi). Mi rendo conto che ho
liquidato l'argomento, ma ho paura che rischiamo di creare il thread piu'
lungo e noioso della storia ;)


-- 
Roberto De Ioris
http://unbit.it