Re: [Python] web: sync vs. async

[Daniele Varrazzo]

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. Ora mi sembra tu 
preferisca non prendere in considerazione i greenlet, preferendo una 
soluzione web server + fork + (eventualmente multithread nei diversi 
processi).


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


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


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?

Grazie!

--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

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

Re: [Python] web: sync vs. async

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 04/12/2011 10:59, Roberto De Ioris ha scritto:
> [...]
> 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)
> 

Si, questo è il problema maggiore con le coroutine.
In parte il problema si può ridurre allocando memoria virtuale, ma il
problema di fondo resta.

Tempo fa lessi il codice del runtime di GHC (compilatore per Haskell)
che implementa un modello a microthread, ma non ci ho capito niente ;-).

So solo che ciascun micro thread richiede poca memoria, però il runtime
deve controllare eventuali stack overflow e riallocare lo 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()).
> 

Io devo ancora capire greenlet come gestisce il problema dello stack.
So che copia delle aree di memoria, ma non so bene cosa.

> [...]
> 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"). 


Si, su questo la pensiamo allo stesso modo.

> 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).

Io stavo valutando un altra strada (nel caso in cui non serva un elevato
grado di concorrenza): il buon vecchio CGI.
Ovviamente non CGI normale, ma fare in modo che l'interprete Python sia
embedato nel server (e pre-caricare in memoria quanto più possibile
specialmente se read-only) e poi fare un fork + Python exec.

Rispetto ad un CGI normale (fork + sys exec) mi aspetto un miglioramento
significativo, anche grazie al copy-on-write.

Lo volevo fare in Nginx e, per riutilizzare tutta l'infrastruttura,
usare 1 UNIX domain socket invece che 2 pipe, ma non è banale e richiede
di patchare il codice di Nginx.

> [...]


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

iEYEARECAAYFAk7blFsACgkQscQJ24LbaUSKVACfdfDx5PLAlMDe8eADtso9TJlM
MMQAnRXJM9t1Sl4bGUrUvNLd+0kJbBPl
=3jIy
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] web: sync vs. async

[Alessandro Dentella]

Grazie Daniele per i molti stimoli, ma vorrei capire meglio...

On Fri, Dec 02, 2011 at 08:44:26PM +, Daniele Varrazzo wrote:
> >Comincerei a pensare di usare un server non bloccante (e magari le
> >greenlet per avere una API familiare) *solo* se l'applicazione deve
> >scalare su migliaia di richieste ed è fondamentale non sprecare
> >risorse
> >su processi/threads.
> 
> I thread non sono una faccenda di risorse sprecate su Python: sono
> una faccenda di lock contention, e scala maledettamente male: nelle
> poche decine, anche se la macchina permetterebbe ben altro. Nessuno

Se il problema è la lock contention, non vedo come una soluzione asincrona
migliori o scali meglio. Se due chiamate devono contendersi uno stesso dato
dovrò sempre attuare le stesse strategie anche in modalità
asincrona. Sbaglio?

Nel caso per cui ho fatto partire questa discussione poi ho concorrenza
molto limitata (in pratica solo con chiamate generate dalla stessa pagina
web, non da altri utenti)

> dei nostri programmi (sia web che altro, ma con necessità di
> concorrenza) è "sopravvissuto al proprio successo" senza venire
> sbudellato (chi ribasato su greenlet, chi riscritto in erlang...) Il
> sito web di cui ho parlato oggi ha pochi clienti ma è molto
> cpu-intensive e nei giorni di maggiore attività non reggeva 80
> clienti connessi prima di splittarlo.
> 
> Il problema di Alessandro non è quello di scalare: ha verificato che
> la sua macchina è praticamente inattiva per tutto il tempo. Se
> risolve il problema del database che lo blocca dovrebbe stare a
> cavallo. Poi non è che si sia prodigato in dettagli: magari il
> blocco è nel db che offre poche connessioni, non si sa se il db sia
> sulla stessa macchina... un po' di lavoro deve farlo anche lui, non
> possiamo mica debuggare con la telepatia, no? :) Magari quella cosa
> di psycopg + async funziona bene: in fondo quella di twisted pare
> vada. E non lo costringerebbe a scrivere il programma da zero.

La soluzione che hai indicato -il modulo momoko- è interessante ma se non
capisco male mi costringe comunque a riscrivere tutto. Come ho scritto,
l'applicazione al momento usa intensamente SqlAlchemy, non direttamente
psycopg2. Il modulo momoko prevede che uno scriva le SQL dirette, non che
passi da un ORM. Non mi pare [1] che Mike Bayer abbia progetti di
avventurarsi in una versione asincrona di SqlAlchemy.



sandro
*:-)

[1] 
http://groups.google.com/group/sqlalchemy/browse_thread/thread/c84b33a38540547e



___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python