[Python] web: sync vs. async

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 04/12/2011 09:56, Daniele Varrazzo ha scritto:
> On Sat, 03 Dec 2011 15:51:08 +0100, Manlio Perillo wrote:
>> Il 02/12/2011 23:25, Daniele Varrazzo ha scritto:
> [tante cose]
> 
> Manlio, una curiosità:
> 
> qualunque cosa si cerchi su google riguardo nginx/greenlet/wsgi, spunta
> il tuo nome con qualche lavoro che hai fatto.

Si vince qualcosa? :)

> Ora mi sembra tu
> preferisca non prendere in considerazione i greenlet,

Tempo fa ci avevo giocato.
Avevo anche sviluppato questo:
https://bitbucket.org/mperillo/txwsgi/

(in realtà lo feci perchè volevo una implementazione di riferimento e di
test per un modello analogo da implementare per il mio modulo wsgi per
Nginx).

In quel periodo ricordo che stavi rilasciando il supporto per l'api
asincrona a psycopg2 e volevo aggiungere un esempio per txwsgi, ma poi
ho avuto altro da fare.

Il problema è che greenlet (e quello che gli gira attorno) non mi ispira
molta aria di robustezza.
Magari è solo una impressione (errata), eh.

> preferendo una
> soluzione web server + fork + (eventualmente multithread nei diversi
> processi).
> 

I thread, a meno di esigenze particolari, li lascerei stare (altrimenti
se continuiamo così ogni volta che cerchi su google multithread è capace
che esce il mio nome :) ).

> C'è qualcosa che ti ha fatto cambiare idea? Dopo averci giocato hai
> capito che coi greenlet ci sono ostacoli? Qualche esperienza da raccontare?
> 

Come detto, solo impressioni.

> Io come ho detto un'esperienza di "sito web classico" (non molto da fare
> per ogni richiesta, ma molte richieste) non ce l'ho di recente; ho
> provato a googlare per vedere le diverse possibilità di deploy e uno
> degli hit più esaustivi che ho (ri)trovato è stato il mega-confronto di
> Nicholas Piël <http://nichol.as/benchmark-of-python-web-servers>. Tutte
> le soluzioni greenelt sembrano utilizzare un web server proprio, il che
> mi ha sempre vagamente (forse irrazionalmente) innervosito. Questo
> costringe il web server Python anche a servire le risorse statiche,
> compito per cui altri web server (in C) mi sembrano più portati.
> 
> C'è una soluzione che tu sappia per avere un web server di fronte (nginx
> ad esempio, ma eventualmente apache o altri) e uno/più processi python
> alle spalle, ognuno in grado di servire più richieste ma usando i
> greenlet anziché thread?
>

Ci stavo lavorando per il mio modulo wsgi per Nginx, ma poi non ho avuto
voglia di continuare (vedi la mia impressione su greenlet).

Anche txwsgi è una alternativa, già funzionante (nel senso che il
supporto a greenlet c'è già anche se un pò bizzarro).

Comunque, per essere sicuro di aver capito, intendi forse una soluzione
in cui il codice Python è embedato in un server scritto in C?

> 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?
> 

Purtroppo non sono in grado di risponderti.
Diversi test che ho letto non mi erano sembrati fatti bene; farli bene
non è banale e richiedono un certo impegno (anche hardware visto che ti
servono almeno 2 macchine per fare test decenti di una applicazione
client/server).

Magari quelli di Unbit possono tirare fuori un test definitivo?
So che esiste un software per i benchmarking distribuito scritto in
Erlang (Tsung), ma non l'ho mai usato.


Ciao  Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7bkdgACgkQscQJ24LbaUSscgCfQobd/8aL7GbOXVbxwHdBU/8P
0fgAn3S/Qt7lI6X1QSWCCO1Sy3jkq+Y2
=HuK5
-----END PGP SIGNATURE-----