[Python] web: sync vs. async

[Manlio Perillo]

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

Il 02/12/2011 21:44, Daniele Varrazzo ha scritto:
> On Fri, 02 Dec 2011 20:18:18 +0100, Manlio Perillo wrote:
> 
>> IMHO, nel caso in questione, è meglio cambiare web server usando ad
>> esempio Apache + mod_wsgi.
> 
> Chiedi ad AD se ha voglia di riscrivere tutto il programma...
> 

Non conosco Tornado, ma stavo assumendo offrisse un API compatibile con
WSGI, in modo che il porting ad un altro web server sia quasi immediato.

>> In questo caso hai un pool di processi che gestiscono le richieste e
>> dovresti essere a posto (ma hai anche la possibilità di usare i thread,
>> e con psycopg2 può essere una alternativa).
> 
> Stai sempre parlando di scrivere un programma da zero con certe
> specifiche, tipo non avere stato al di fuori del database, che non è
> detto siano quelle di Alessandro (lui ha detto "Ogni chiamata dallo
> stesso client cambia dati nella sessione che devono quindi essere
> sincronizzati fra una chiamata e l'altra": non so se intende stato in
> memoria o nel db; il process pooling dell'applicazione implica zero
> stato per client in memoria)
> 

Si, è da verificare.

> Scusa, ma tu veramente ti sentiresti di consigliare una soluzione web
> python basata su thread e di sostenere che questa possa scalare?

Non ho mai detto una cosa del genere.

Anzi, mi sembra di aver detto chiaramente che, dato che Alessandro non
ha bisogno di scalare, **non** ha bisogno di usare cose come Tornado ma
può fare affidamento sul robusto Apache + mod_wsgi.
Di default io non userei i thread, comunque.

> Non
> parlo di milioni di utenti, parlo di centinaia.

E credi che Apache abbia problemi con questo tipo di concorrenza?
Non ho esperienza diretta, ma mi sembrerebbe strano.

Probabilmente sprechi più memoria.

> Veramente ritieni che
> buttare thread in python sia una soluzione buona quanto usare metodi
> asincroni nei diversi modi possibili (greenlet, twisted, yield-based ecc).
>

Se devi sopportare carichi non eccessivi credo di si.

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

Il collo di bottiglia di Alessandro sembra essere l'accesso al database,
e psycopg2 rilascia il lock.

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

Usando thread o processi?
Che tipo di hardware e che web server (nel caso di applicazioni web)?
Quante connessioni concorrenti?

Infine una curiosità: assumendo che sia il vecchio che il nuovo
application server offrano WSGI e che nel nuovo usi greenlet, quanto
impegno ha preso la riscrittura dell'applicazione?


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

Splittarlo su N processi fissi: quindi mi aspetto che Apache + mod_wsgi
con N processi worker non abbia troppi problemi.

Magari mi aspetto troppo da Apache, ma se la tua soluzione funziona e
Apache no, significa che mi sono perso qualcosa.

> [...]


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

iEYEARECAAYFAk7ZSMwACgkQscQJ24LbaURoHgCfdumEfrFFnvuG+YZI2Dt8F+CN
knoAoIil0x0Ti08LxBDZE3jt1S8z/LMA
=OH73
-----END PGP SIGNATURE-----