> 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 _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
