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

[Alessandro Dentella]

On Tue, Dec 13, 2011 at 03:16:49PM +0100, Manlio Perillo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Il 13/12/2011 14:38, Alessandro Dentella ha scritto:
> > [...]
> > Non sono stati differenti, è sempre la stessa cosa (la sessione) che viene
> > memorizzata o in ram o in redis o in postgres: voglio scegliere la soluzione
> > più idonea per quel particolare tipo di applicazione. 
> > 
> > Lo stato in memoria non mi piace: non posso riavviare il server con
> > serenità. Eliminata questa richiesta non ho neanche più la necessità della
> > session affinity. 
> > 
> > Redis è stato introdotto per affrontare il problema di rallentamenti come
> > storage per le sessioni ma come errata diagnosi, ora non è più necessario
> > anche perché dalle mie prove (assolutamente primitive) non si guadagna nulla
> > di interessante rispetto al db.
> 
> Davvero?
> Mi aspetto che, per delle semplici sessioni (storage key-value) redis
> sia significativamente più veloce di un database relazionale.

Lo è, ma stiamo parlando di numeri molti piccoli per le mie
esigenze. Recuperare una sessione 'media' da pg mi prende 1.0 ms,
recupararla da redis può prendere anche 5/6 volte meno. Se la sessione è
grande l'unpickle prende oltre i 20 ms, quindi l'ottimizzazione non è certo
da cercare in redis ma in una ottimizzazione di ciò che sta nella sessione.

> > E la velocità non è il problema in ogni caso.
> > 
> >> Quanta roba ci dovete scrivere nelle sessioni, che le richieste ajax
> >> si inciampano a vicenda? Nella sessione scrivici l'id dell'utente e
> >> basta, lo scrivi al login e lo usi solo per leggere. Mi sembra di
> >> capire che ogni richiesta ci scriva qualcosa: perché lo scrivi nella
> >> sessione e non lo tieni in memoria o in redis?
> > 
> > che vantaggio mi darebbe tenerlo in redis?
> > 
> 
> Accesso ragionevolmente efficiente ed atomico + consistenza dei dati.
> Inoltre non hai il problema della session affinity.

io intendevo rispetto al db non rispetto alla RAM

> Ti resta da decidere se usare PostgreSQL o Redis.

Esatto, ed io propendo per pg. Prima che Daniele mi massacrasse sulla
questione del "select for update" la preferivo anche per la possibilità di
scegliere che alcune sessioni le prendo garantendo la sequenzialità (quelle
che servono la spreadsheet). Ora ci rifletterò e se anche dovessi scegliere
la strada della perdizione mi sa che non lo dico in lista :-)

> Le sessioni come sono strutturate?

confesso che ne so ancora poco. Ho preso in mano questa situazione da un
paio di settimane ma non a tempo pieno e altre cose hanno reclamato la mia
attenzione. Chiaramente, per i motivi di cui sopra varrà la pena analizzare.

Visto che tu conosci bene nginix, ip_hash è totalmente affidabile per la
session affinity?, abbiamo avuto alcuni comportamenti strani dopo avere
attivato il setup con svariate istanze di tornado su 2 server che si risolvevano
dirottando verso una seconda istanza di nginix con un solo server (e due
tornado) non sono sicuro che fosse un problema di sessioni, ma il tarlo
ce l'ho...

sandro
*:-)