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