Catturare il Timeout

12/04/2013 20:57:18

Capito grazie :D. Però mi sembra strano che possa usare soltanto i cron job. Magari ci sta un listener che s'imposta nel php.ini ... boh , mi farò un giro per la rete e vedere se ci stanno anche altre possibilità, se trovo qualcosa vi faccio sapere.

12/04/2013 23:09:40

Un'altra soluzione esiste, non migliora molto il problema delle tempistiche ma toglie di mezzo la necessità di doverti costruire un garbage collector per le sessioni non chiuse con un cron job.

Il problema che stai cercando di risolvere tu qui è la conseguenza di un altro "problema" nascosto a livello più basso nel design del tuo sito:
stai gestendo la sessione degli utenti con due sistemi differenti.
Il primo sistema è il meccanismo sessioni di PHP che si occupa di collegarsi con il browser e associarlo a un'insieme di dati dentro all'array $_SESSION. Il secondo sistema è la tabella nel tuo database che tiene traccia di chi c'è online.
Il problema sta nel fatto che questi due sistemi non sono sincronizzati, quando la sessione PHP scade non c'è modo per dire alla sessione nel DB di cancellarsi.

Cosa succederebbe se invece tu potessi unire questi due sistemi in un sistema unico e fare in modo che quando la sessione PHP scade il record nel db sparisca in automatico? Spostare tutto completamente sul db, così che tu abbia più controllo sui dati di sessione.
PHP offre la possibilità di personalizzare il gestore della sessione con la funzione: session_set_save_handler http://it2.php.net/manual/en/function.session-set-save-handler.php ↗
è molto semplice: devi solo scrivere le funzioni per creare, cancellare, leggere e scrivere i dati nel database e passarle alla funzione qui sopra.

No, questo sistema non risolve completamente il problema che gli utenti non scompaiono quando chiudono il browser, infatti la gestione sessioni di PHP lavora anche lei con un intervallo di tempo che man mano invalida i dati di sessione, perciò ci sarà sempre e comunque un periodo di tempo in cui l'utente risulterà online quando in realtà non lo è.
Allora dov'è il vantaggio nell'usare questo sistema? Il vantaggio sta nel fatto che ora hai un unico sistema per gestire la sessione, e quindi non hai più bisogno di costruire un sistema che pulisca le sessioni rimaste aperte (niente cron, niente richiamare una funzione di pulizia a ogni esecuzione o cose del genere) perchè se ne occuperà php internamente a richiamare le funzioni che tu gli hai fornito.

(Il sistema interno di PHP è comunque molto simile all'eseguire una funzione ogni esecuzione, ma viene fatto in modo statistico e quasi trasparente per te, che quindi non dovrai più occuparti di progettare un ulteriore sistema di manutenzione della sessione dato che ne esiste già uno)

12/04/2013 23:24:57

Do un'occhiata a questa soluzione :). Comunque il problema non è quello di far scomparire l'utente immediatamente anche senza aver cliccato sul Logout, ma evitare di fare pooling su query tutto qui :).

Vediamo se questa soluzione con MYSQL andrà bene :).

12/04/2013 23:49:12

Beh i cicli di cancellazione delle sessioni scadute avvengono in modo statistico. Puoi controllare la probabilità di esecuzione con un paio di direttive in php.ini, di default la probabilità è di un millesimo se non ricordo male. Se hai accesso a quelle variabili puoi controllare quanto spesso (statisticamente) parte il garbage collector, e adattarlo alla grandezza del tuo sito, così da non avere un peso sul db troppo spesso.

13/04/2013 10:54:53

Cronjobs: esistono proprio per questo tipo di operazioni.

Tuttavia, nel caso non si disponesse della possibilità di usufruirne, puoi crearne una versione spartana con un workaround sicuramente non elegantissimo ma funzionale.

1. Nel momento in cui un utente qualsiasi ti lancia l'aggiornamento su tutti, memorizzi il timestamp ( funzione time() di php ) in un file di testo, avendo cura di impostare un lock esclusivo sull'operazione ( puoi fare tutto in un unica istruzione con file_put_contents() ).

2. At this point, ogni singolo utente verifica l'esistenza del file e si carica il timestamp che esso contiene in sessione (in questo modo eviti di chiamare più del dovuto il file testuale in lettura).

3. Ad ogni refresh di un utente verificherai quindi che il tempo attuale sottratto del tempo memorizzato in sessione non sia maggiore di 600 secondi (10 minuti).

4. Quando passano i famosi 600 secondi il primo utente che giunge lancerà la procedura di controllo su tutti ( la funzione ignore_user_abort() può esserti estremamente d'aiuto ).
A questo punto la logica riparte dal punto 1.


Puoi semplificare tutto il processo in una singola funzione, così fai un singolo richiamo in cima ad un eventuale front controller pattern ed hai risolto.


Have Fun!

13/04/2013 14:07:33

blancks

E lavoro con i file di testo e non con il database almeno per controllare ... in teoria dovrebbe essere più performante la lettura o scrittura di un file di testo rispetto all'accesso al db giusto?

13/04/2013 21:10:42

salvuzzo87 ha scritto: [quote]blancks

in teoria dovrebbe essere più performante la lettura o scrittura di un file di testo rispetto all'accesso al db giusto?[/quote]

In generale: dipende, mysql ha una sua cache e richieste frequenti che riportano il medesimo recordset finiscono con lo stressare di meno la cpu nel lungo periodo.

Nel caso specifico che ti ho riportato d'esempio, ogni utente dovrebbe leggere il file di testo una volta ogni 10 minuti (perchè dopo il lavoro lo fai controllando la sessione quindi non richiami più il file in lettura prima della scadenza). La lettura da file è generalmente molto veloce, per quanto riguarda la scrittura invece è sicuramente più lenta come operazione ma nel contesto che ti ho descritto dovrebbe avvenire precisamente una volta ogni 10 minuti (in quanto viene lanciata dal primo utente che effettua il controllo passati i 600 secondi).

A rigor di logica l'andazzo della cosa dovrebbe essere così:

. Primo utente che s'accorge che sono trascorsi 600 secondi dal timestamp in sessione, lancia la procedura di aggiornamento presenti su tutti.
. Il file testuale viene aggiornato da quel primo utente col timestamp attuale.
. Tutti gli utenti a questo punto effettuano il loro pollig e leggendo il file si osserva che non sono ancora passati i 600 secondi, memorizzano quindi il contenuto del file in sessione.
. Per ogni refresh che fanno nel sito ogni utente controlla che tra il tempo in sessione e il tempo attuale non passino i famosi 600 secondi.
. Il primo che rileva sono passati più di 600 secondi ripete il giro di aggiornamento.


Ipotizzando il caso di 100 utenti perennemente online e attivi sul sito per 24h otterresti:

. 14400 letture da file(anzichè query select)
. 144 scritture sul file.
. 144 query di aggiornamento utenti.


Senza cron, penso sia il meglio che puoi ottenere. ( ti consiglio di fare i conti su una media di 35 online per cominciare però, visto che mi sembra più plausibile, oh poi ti auguro pure di scalare i 100 un domani ;) )

21/04/2013 02:28:21

Ciao Ragazzi:)
Sto implementando le due logiche per gli utenti online. Sia quella col Database che quella del file di testo proposto da blancks.

Per quanto riguarda la seconda soluzione non ho capito una cosuccia. Allora, salgo il timestamp nel file di testo e in sessione il time, in modo tale che quando implemento il pooling nn vado a caricare il file di testo ma a leggere il time in sessione. Se verifico che è passato tanto tempo allora faccio un update su tutti gli utenti. La mia domanda però è questa.

Per ogni utente, che fa qualcosa sul gdr, vado ad aggiornargli il timestamp relativo alla sua utenza?

Grazie ancora dell'aiuto :D.