[Python] web2py: lo conoscete -> sessioni su db

[Alessandro Dentella]

Comincio dal fondo, forse risulta più chiaro il tutto.

On Mon, Dec 12, 2011 at 10:13:48PM +0000, Daniele Varrazzo wrote:
> A proposito, poi com'è andata con la storia di tornado e psycopg?

bene! con 10 processi tornado i tempi si sono azzerati, la cpu continua a essere
inutilizzata e la ram pure. La situazione attuale è quindi buona come
performance ma bastarda nella natura (un server nato per essere usato in modo
asyncrono e poi reso parallelo con differenti processi.) Personalmente sarei
più contento di spostarlo su un altro framework, ma la scelta la faremo dopo
avere analizzato cosa altro devono sviluppare.

La session affinity è necessaria perché la sessione viene presa dalla RAM se
esiste altrimenti da Redis, e salvata poi comunque su Redis. Il fatto di
prenderla dalla RAM è odioso in quanto mi crea problemi a restartare il
server, e presto cambierà. 


> On Mon, 12 Dec 2011 18:49:38 +0100, Alessandro Dentella wrote:
> >On Fri, Dec 02, 2011 at 03:37:34PM +0000, Daniele Varrazzo wrote:
> >>Ah, cherrypy è multithread, ma lo storage su file delle sessioni non
> >>è thread safe, me lo sono dovuto scrivere io. Mi chiedevo come mai
> >>l'autore originale del programma usasse memcached solo per salvare
> >>(si fa per dire le sessioni). Quando abbiamo fatto il multi-nodo, un
> >>mio collega ha visto lo storage delle sessioni su database (che
> >>potrebbe servirci se volessimo scalare su diverse macchine) e ha
> >>detto che anche quello è finto.
> >
> >Nel cammino verso l'indipendenza dell'applicativo dal processo voglio
> >portare le sessioni su database.
> 
> Uhm... ok... su file non vanno più bene? Assumo che lo vogliate fare
> per scalare oltre la singola macchina, altrimenti non c'è ragione.

non sono su file, in questo momento sono... 1/2 in ram e 1/2 su Redis. Non
si erano ancora resi conto che è bacato solo perché la usavano in modo
sincrono e con un solo processo. Non trovo comoda la session affinity
soprattutto in quanto non necessaria accettando il costo di qualche
millisecondo per prendere e scrivere la session su db

> >Considerando che attualmente le singole request vengono evase in
> >100 ms
> >circa, pensavo di farlo utilizzando SELECT FOR UPDATE, così da
> >garantirmi
> >che nessun'altra request possa leggere finché non ho evaso la
> >request.
> 
> E perché vorresti impedire di leggere? Uno fa tanto per progettare
> un database che consenta letture e scritture concorrenti e tu infili
> gli un ombrello nella ruota davanti? :)

come la metti giù dura! Quelli che fanno tutta quella fatica a progettare i
db hanno anche pensato alla utilità del "SELECT FOR UPDATE", quelli di
postgresql poi l'hanno fatto selettivo al singolo record, ed in lettura mica
mi si blocca se non uso "FOR UPDATE". L'update della sessione lo blocco dove
mi serve!

Attualmente scrivono e se ne fregano, il risultato è che alcuni dati vengono
sovrascritti, quindi se il controllo lo devo fare, tanto vale farlo
prima, visto che esiste un modo così semplice.

Il programma è una griglia che viene compilata, ad ogni cambio cella parte
una richiesta ajax. La probabilità che uno "si incespichi con sè stesso" è
comunque bassa, quindi non mi aspetto che si debbano perdere molti ms.


> >Ci sono idee migliori o controindicazioni? (a parte che tengo
> >occupata una
> >connessione solo per questa transazione)
> 
> Controindicazioni dei lock espliciti? Quante ne vuoi. Non è una
> buona idea. Sono pochi i problemi che hanno davvero bisogno di un
> lock per essere risolti, e tu non sei neanche sicuro di avere un
> problema: ti direi lascia perdere che rischi di fare più danni di
> quelli di cui hai bisogno.

il problema c'è ed è tangibile 

> 
> >Guadando il codice di django non ci leggo precauzioni contro questa
> >eventualità, mi sfuggono o cherry-py non è solo?
> 
> Forse semplicemente non è un problema. Se hai un burst di letture
> sullo stesso utente dovuto a richieste asincrone, dovrebbero leggere
> tutte uno stato consistente della sessione. I problemi di cherrypy

non è così, leggono e cambiano la sessione, la successiva deve leggere i
nuovi valori. Hanno voluto aspettare a salvare sul db per offrire una
opzione di salvare o annullare e -per come è fatta ora la soluzione-
lasciano in sessione un tot di dati. 


> sono ridicolamente altri, secondo me django due o tre persone
> l'hanno testato e va bene così com'è. Con cherrypy a volte le

(due o tre? allora le conosco tutte! ;-)

> sessioni leggevano un file e lo trovavano vuoto perché la richiesta
> di prima l'aveva aperto per scrivere (con open(name, 'w')) e non
> l'aveva ancora chiuso; con postgres questo problema non esiste: o il
> vecchio, o il nuovo, ma un record consistente ce lo trovi. Le

ma se è vecchio non mi serve! allora meglio aspettare per avere il nuovo...

> Controindicazioni dei lock espliciti? Quante ne vuoi. Non è una

Dai dammene qualcuna di convincente...


sandro
*:-)