Catturare il Timeout

11/04/2013 19:01:55 e modificato da yamada il 11/04/2013 19:17:55

Sicuramente giusta l'idea di far refreshare all'utente la propria presenza con time().

Sicuramente sbagliato far cancellare agli utenti attivi gli utenti inattivi. Non è vero che la query è ogni 10 minuti (questa è solo la teoria). In realtà è ogni 10 minuti se l'utente non preme mai AGGIORNA. Se lo facesse molto probabilmente (quasi sicuro diciamo siccome lo fanno quasi tutte le land) l'utente ricaricherà il ciclo di controllo dall'inizio e quindi rifarà il controllo iniziale per poi aspettare 10 minuti.... sempre se non fai aggiorna ovviamente!

Cosa peggiore è il fatto che se hai 100 utenti connessi ognuno di loro controlla che gli altri 99 non siano outoftime ed eventualmente li cancella: sicuramente un sistema non ottimizzato di gestione delle risorse... inoltre supponendo che i 100 utenti avessero il ciclo ogni 600 secondi (10 minuti) per assurdo (quasi impossibile) in maniera uniformemente distrubuita avresti una query di controllo ogni 6 secondi (600 / 100 utenti). Direi che è alquanto stupido. Basta un singolo controllo ogni 10 minuti. Un refresh così frequente non ha senso.

ultima cosa il sistema fallisce totalmente nel caso nessuno rimanga connesso attivamente: siccome ogni utente ATTIVO controlla gli inattivi cosa succede se TUTTI gli attivi escono premendo "X" (pochi fanno realmente il logout)?? succede che risulteranno ONLINE anche dopo ORE finche un nuovo utente si connetterà e diventando ATTIVO andrà a cancellare gli utenti inattivi.


sicuramente il sistema funziona a livello pratico ma di certo non è così che si programma.

quota

11/04/2013 19:19:31

Non importa in che stato si trova il sistema quando non c'è nessuno a osservarlo, l'importante è che sia nello stato corretto non appena entra qualcuno.
Che sistema utilizzeresti invece?

---

quota

11/04/2013 19:32:42 e modificato da yamada il 11/04/2013 19:40:39

ovviamente un cron_job su singolo file PHP che controlla tutti gli utenti online ogni 10 minuti.

Il sistema è perfetto sotto ogni aspetto perchè:

1) il controllo avviene sicuramente ogni 10 minuti poichè server side per un totale giornaliero di 144 controlli giornalieri (24 ore) sia che ho 1 utente sia che ne ho 10000.

con il sistema da voi utilizzato supponendo 100 utenti connessi che non premono MAI aggiorna (lanciando un controllo anticipato) fai quotidianamente (24 ore) 14400 controlli.

2) il sistema funziona anche con un utente connesso. quando quest'ultimo si disconnette il sistema lo cancellerà dopo 20 minuti (10 solo se si disconnette nell'esatto secondo il cui il cron job entra in esecuzione).

Ecco come fare la stessa cosa utilizzando 1/100 delle risorse (come minimo perchè OVVIAMENTE si preme aggiorna in una land per molteplici motivi) in maniera ottimizzata.

con l'altro sistema più utenti hai e più mangi risorse. Qui hai una spesa fissa (irrisoria) indipendentemente dal numero di utenti connessi.

Il mio sistema rimane fallimentare solo in un caso: se nessuno è connesso durante TUTTO l'arco della giornata poichè faresti 144 controlli inutili ma a quel punto tanto vale che chiudi la land se non gioca MAI nessuno.

quota

11/04/2013 19:36:51 e modificato da darkabe il 11/04/2013 19:38:04

Scusami ma non l'ho capita.. che deve aggiornare? Ti riferisci al fatto che dovrebbe aggiornare l'intera pagina, cambiandola? La mia versione dell'algoritmo, anche se non l'ho scritto, prevedeva una land priva di href nudi e crudi in favore delle chiamate asincrone, quindi è davvero difficile trovare qualcuno che possa ricaricare la pagina se non intenzionalmente con F5.

Una select ogni 6 secondi è ben lungi dall'essere considerata "carico di server", ma in ogni caso l'alternativa corretta sarebbe delegare al server le operazioni del server.. con quel che ne deriva. Non tutti gli hoster mettono a disposizione la possibilità di lasciar caricare script che girino lato server, quindi l'alternativa sono i cronjob.. che nei casi più comuni sono molto limitati, con restrizioni come "un solo cronjob ad intervalli non più piccoli di 1 ora".

Sarà pure la soluzione ottimale, ma è quella che richiede più cose alla base. Sempre se non esista altro metodo altrettanto efficace ed a me sconosciuto..



EDIT: ho letto ora la risposta, resta comunque valido il discorso che ho fatto..

quota

11/04/2013 19:46:08

qui si parla di programmazione non applicata al singolo caso. personalmente utilizzo circa 20 cron jobs per svariati motivi. se dovessi applicare "tante select ogni 6 secondi fatte dagli utenti" per gli script che girano su ngdr userei più del 50% delle risorse in più. (attualmente uso il 2-3% del server a livello di cpucon 70 online).

mysqld è per altro sicuramente il processo che è meglio usare di meno se si vuole risparmiare in risorse.

quota

11/04/2013 21:27:33 e modificato da ilgrandeinverno il 11/04/2013 21:43:29

Assolutamente d'accordo con yamada per quanto riguarda l'ottimizzazione delle query di controllo.

Tengo a specificare che non sono entrato in dettaglio per quanto riguarda la modalità di esecuzione della query che cancella gli offline per un unico motivo: non tutti gli hosting offrono i conjobs. Aruba, tanto per dirne uno, di base non li offre nel suo pacchetto hosting.

Di conseguenza il problema per chi non ha a disposizione i cronjobs va affrontato diversamente, specie nel caso in cui non si abbiano a disposizione (o non si vogliano utilizzare) servizi esterni che lancino script di controllo/manutenzione a intervalli così frequenti.

Resta inteso che questo discorso vale per TUTTE le query eseguite ad ogni refresh regolare: se lo stesso frame (ipotizzando che sia un frame) che fa il refresh automatico ogni X minuti esegue, per ogni utente collegato, altre query, con 100 utenti collegati e refresh ogni 10 minuti avrai sempre 600 query ora = 14400 query al giorno (teoriche ipotizzando 100 connessi fissi per 24 ore su 24).

Generalmente gli autorefresh vengono usati non solo per tenere viva la sessione e aggiornare i presenti ma anche per altre funzionalità, dal controllo della posta, all'aggiornamento di parametri di pg ed oggetti, all'innesco/controllo di funzioni di interesse generale come meteo ecc.

Il che significa che 14400 va moltiplicato per il numero di operazioni che il frame autorefreshante esegue. Diciamo che ne fa 5 (controllo "non ottimizzato" dei presenti compreso). Sono 3000 query/h anzichè 600 = 72000 query / giorno. E la rimozione della query di controllo sugli online si rivela sostanzialmente ininfluente sul consumo generale di risorse.

Soprattutto considerando che il 99% delle land attive é ben lungi dall'avere anche solo la metà dei 100 utenti online ipotizzati e tantopiù é ben lungi dall'averli per 24 ore su 24.

E consideriamo anche che in genere i tempi di refresh sono anche più frequenti, perchè il giocatore medio tende a lamentarsi con foga se l'avviso che c'è una nuova missiva non gli arriva subito.

Quindi, posto che il tuo discorso é assolutamente corretto in termini teorici e in termini di BUONE ABITUDINI pratiche da assumere nel programmare e soprattutto nel gestire la manutenzione del proprio database senza rischiare picchi di consumo delle risorse, vale la pena di ricordare che sulla land media l'impatto di una singola query (di questo tipo) in più o in meno é sostanzialmente ininfluente e che di sicuro la land non andrà mai in crash per questo.


PS: per chi non può / non vuole avvalersi di servizi esterni in grado di simulare un cronjob e sta su un provider che non offre i cronjob, vanno studiati modi alternativi per ridurre i consumi di risorse. I frame autoaggiornanti degli utenti sono un ottimo checker, ma eventualmente puoi far innestare il check da qualunque operazione che l'utente esegue (statisticamente) con una frequenza utile ai tuoi scopi.

Es: non avendo cronjobs a disposizione potresti eseguire la query di controllo se e solo se l'orario rispetta determinati requisiti (es. se il numero di minuti dell'ora corrente é multiplo di 10). Non elimini il problema del picco, perchè al verificarsi della condizione scelta, TUTTI gli utenti che refreshano nelle stesse condizioni invieranno la query di controllo, ma almeno ti risparmi di inviarle di continuo.

Però occhio: il picco di consumo di risorse a seconda delle condizioni che stabilisci, potresti essere proprio tu a crearlo nell'ansia di ridurre il numero di query che, "spalmate", invece non avrebbero impatti percepibili.

Io più che fare una valutazione teorica a tavolino, se non hai i cronjob a disposizione, farei una valutazione statistica pragmatica sulla base della tua utenza media per scegliere la soluzione migliore.

---

quota

11/04/2013 23:34:37 e modificato da salvuzzo87 il 11/04/2013 23:52:14

Ah, ottima idea quello del cronjob php... se non sbaglio sarebbe il --q vero?? Si meno sprego di risorse senza dubbio :) Grazie mille per le informazioni :D per altri problemi (visto che ne sapete molto ma molto più di me essendo un novizio di PHP non esiterò a scrivere) :)

Hmm però leggendo su internet non tutti i domini supportano i cron-job. Che voi sappiate altervista è uno di questi?

quota

12/04/2013 12:45:01

Non uso spesso altervista, ma da quanto mi è sembrato di vedere i cronjob ci sono.. ma non gratis.

Li trovi sotto la voce "Tools", ma credo proprio tu debba comprare il numero di esecuzioni (quindi se ne hai 1 che parte solo a mezzanotte, dovrebbero esser 365 esecuzioni annue).
Se l'ho inteso bene è altamente sconveniente averne uno che parte ogni ora, figuriamoci ogni 10 minuti..

Qualcuno che usa Altervista più di me mi smentisca se ho detto qualche fesseria :-P

quota

12/04/2013 15:08:58

I cron job su altervista si pagano ad esecuzione:
100 ESECUZIONI 0.20 euro
500 ESECUZIONI 1 euro
1000 ESECUZIONI 2 euro
10000 ESECUZIONI 10 euro

---

quota

12/04/2013 17:18:27

Per chi non avesse problemi ad affidarsi a un servizio esterno:
SETCRONJOB.COM https://www.setcronjob.com/

La versione gratuita (che bisogna ricordarsi di rinnovare ogni mese) assegna 50 punti "spendibili" in uno o più cronjob. I cronjob giornalieri (run period = 24 h) valgono 1 punto ciascuno. Quelli orari (run period = 60 minutes) valgono 24 punti.

Per cronjob ogni 10 minuti si consumano 144 punti, quindi é necessario passare come minimo al piano a pagamento da 10$ annui.

---

quota

Venezuela e RuneScape

La storia dei Venezuelani che sono sopravvissuti alla crisi economica giocando a Old School RuneScape

Erant

Intervista allo staff di Erant il play by chat fantasy storico da giocare su Discord!

Gdr by Chat Requiem

Nel mondo dei giochi on line il gdr by chat è ormai un pezzo da museo.. questa la teoria di Ivan da leggere e commentare assieme!

Multiverse eLot

Multiverse eLot: intervista al creatore della prima APP per un Play by Chat (eXtremelot)!