[Python] web: sync vs. async

[Alessandro Dentella]

On Fri, Dec 02, 2011 at 08:44:26PM +0000, Daniele Varrazzo wrote:
> 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? :) 

ok, bando alla telepatia... fino a mercoledì stava tutto su una macchina,
ora sta su due, due processi di tornado, un database unico, redis per utenti
e sessioni. La sessione viene scritta su redis come store.

Una istanza di nginx fa da load balancer. Le macchine sono virtualizzate con
VmWare.

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

L'applicazione per quel che ho visto finora è veramente piccola, la
riscrittura, se necessaria sarebbe probabilmente sopportabile, considerando
che molto codice verrebbe riutilizzato.

Sostanzialmente è un foglio elettronico via web, al cambio cella il server
deve calcolare il valore. Lato client è ajax, quindi intrinsecamente
asincrono, ma l'utente vuole vedere subito i valori aggiornati.  Domani mi
dedico a leggere il codice eseguito lato server ma mi pare poco.

In ogni caso anche nel caso suggerito da Daniele vedo qualche riscrittura,
se non altro per il fatto che la soluzione che ha indicato non usa
sqlalchemy ma direttamente psycopg2.

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

*al momento* stanno in memoria (e salvate su redis). Nginx tramite la
 direttiva ip_hash mantiene lo stesso ip sullo stesso server dove al momento
 gira una sola istanza di tornado. 

Nel caso di più processi su porte differenti, come suggerito da Daniele, non
è concettualmente differente da quanto fatto ora, nel caso di più thread o
più processi come potrebbero essere avviati da mod_wsgi, esiste un modo di
garantire l'abbinamento fra un client e "la sua" istanza, sempre quella?
Avevo letto un post del 2007 che indicava come prossimo sviluppo per
mod_wsgi un sistema di stycky session e mi pare che questo mail [1] lo
convalidi. 

sandro


[1] http://groups.google.com/group/modwsgi/browse_thread/thread/b26ba3894632fb0a/51545a7c05bdf6ce