Ridimensionamento di un'app di chat - polling breve rispetto a polling lungo (AJAX, PHP)

Question

Eseguo un sito Web in cui gli utenti possono chattare tra loro tramite il browser (si pensi alla chat di Facebook). Qual è il modo migliore per gestire l'interazione dal vivo? (In questo momento ho un sondaggio che va ogni 30 secondi per aggiornare utenti e nuovi messaggi in arrivo, e un altro sondaggio in corso sulle pagine di chat ogni secondo per ottenere i nuovi messaggi.)

Le cose che ho considerato:

• Socket Web HTML5: non l'ha usato perché non funziona in tutti i browser (solo chrome).
• Socket Flash: non l'ho usato perché volevo alla fine supportare il web mobile.

In questo momento, sto utilizzando il polling breve perché non so quanto sarebbe lungo il polling AJAX scalabile. Al momento sto eseguendo un server VPS da servint (eseguendo apache). Dovrei usare il polling lungo o il polling breve? Non ho bisogno di tempi di risposta assolutamente immediati (solo "abbastanza buono" per un'app di chat). Il sondaggio è breve, spesso con alcune centinaia di migliaia di utenti che uccidono il mio server? Come faccio a ridimensionare questo, per favore aiuto!

Answer 1

Alcune note:

• polling ogni secondo è eccessivo. L'app si sentirà ancora molto reattiva con alcuni secondi di ritardo tra i controlli.
• Per salvare il traffico del db e le risposte di velocità, prendere in considerazione l'utilizzo di una cache in memoria per archiviare i messaggi non consegnati. Si potrebbero ancora persistere messaggi nel db, la cache in memoria verrebbe semplicemente utilizzata per le query per i nuovi messaggi per evitare query al db ogni x secondi da ciascun utente.
• Timeout della chat dell'utente dopo x secondi di inattività per interrompere il polling sul server. Questo assicura che qualcuno che lascia una finestra aperta non continui a generare traffico. Offrire un semplice "Ancora lì? Continua a chattare". collegamento per sessioni che scadono e avvisano l'utente prima del timeout in modo che possano estendere il timeout.
• Suggerirei di iniziare con il polling piuttosto che con la cometa/polling/socket lunghi. Il sondaggio è semplice da costruire e supportare e probabilmente andrà bene a breve termine. Se ottieni molto traffico, puoi ridimensionare l'hardware e il bilanciamento del carico sul problema. L'intero web si basa sul polling: il polling è sicuramente la scala. C'è un punto in cui la complessità delle alternative come cometa/polling lungo/ecc ha senso, ma è necessario molto traffico prima che il tempo e la complessità aggiuntivi siano giustificati.

Answer 2

Questo è qualcosa che tutti hanno fatto una volta prima dell'introduzione di cometd e nodejs.

Il problema, a quanto vedo, è che le richieste PHP su Apache sono molto costose. Se la tua applicazione di chat verifica i messaggi ogni secondo ti troverai in una situazione in cui Apache non dispone di risorse sufficienti per rispondere alle richieste. L'altra area che ritengo debba essere migliorata è quella di migliorare il contesto della tua applicazione di chat.

Perché si aggiorna ogni secondo se non si desidera recuperare nuovi messaggi? Cosa succede se non ci sono messaggi?

Alcune tecniche che è possibile utilizzare;

• Fornire un endpoint leggero ai vostri clienti che ha qualche contesto circa la sessione di chat, è un nuovo messaggio in attesa, quanti messaggi, ecc Il client può rispondere a questa aggiornando immediatamente o se non ci sono nessun nuovo messaggio. Questo endpoint può fornire un semplice oggetto JSON tramite richiesta http. Si è garantito che questo messaggio di stato sarà di dimensioni fisse e se la risposta dello stato non cambia, è possibile decaderne. Vedi il prossimo messaggio.

• Un semplice decadimento nel tuo javascript polling, se il client riceve la stessa risposta dal server alcune volte di seguito puoi incrementare il sondaggio di un tempo prestabilito, al momento hai detto che era ogni secondo. Se lo facessi, incrementeresti ogni 2,4,6,8,10 secondi. Non appena la risposta dal server cambia, resetta il decadimento.

Alcune ottimizzazioni da considerare;

• Utilizzare una cache Opcode PHP come APC.

• Impostare un timeout basso su tutte le richieste, non si desidera alcuna richiesta di blocco del server.

• Ottimizza il codice PHP, rendilo snello e veloce.

• Esegui alcuni test di carico per vedere quali sono i tuoi limiti.

• Prestazioni di benchmark spesso per assicurarsi che le applicazioni diventino più veloci.

• Controllare i registri di apache per i segni tangibili della salute generale dell'applicazione e dei tempi di risposta.

Quando il ridimensionamento diventa necessario, aggiungere un nuovo server e utilizzare un servizio di bilanciamento del carico per distribuire le richieste. Ho usato Varnish e HAProxy con grande successo, non è complicato installarli.

Answer 3

Se fossi in te sceglierei una libreria che utilizza socket web html5 eppure ricade sui socket flash se html5 non è disponibile, il browser che rientra nel crack dovrebbe essere minuto.

Inoltre, è necessario abbandonare php o integrarlo con un server socket socket scritto in python o ruby ​​con em-websocket.