Sto esaminando le applicazioni Web in tempo reale utilizzando websockets e node.js. Sono interessato a vedere quali sono le sfide tecniche con il ridimensionamento di tale impostazione.
Uno di questi problemi è che ogni socket richiede un descrittore di file Unix e epoll / select richiede un tempo lineare rispetto al numero di descrittori di file aperti.
Qualcuno ha altre informazioni sul ridimensionamento?
Esistono due approcci a tutti i server http, thread / processi o asincroni e persistenti.
Twitter è un esempio di cosa evitare a mio parere - fallire balene e tutto il resto. Anche se ora stanno migliorando, il front-end non è ancora persistente ... puoi leggere la sua evoluzione qui: link
La prima cosa che devi riconoscere è che non sarai in grado di realizzare qualsiasi cosa in tempo reale scalabile senza una vera persistenza. Come in un ciclo principale o ciclo di eventi. Se hai una quantità considerevole di codice, PHP, Perl, ecc., Devi rieseguire e ricaricare tutti i loro dati, variabili, ecc. Ogni richiesta, anche se va bene per mostrare il tuo blog Wordpress, questo non funzionerà tipo di applicazione che stai descrivendo.
Se hai abbastanza server e abbastanza soldi puoi usare apache2 / httpd per servire tutto il contenuto in tempo reale. Ma se sei come il resto di noi, probabilmente l'approccio asincrono funzionerà meglio per te.
Tornado - Facebook ha adottato il server Web Tornado per gestire le notifiche degli eventi e gli aggiornamenti dei feed. (Non lo sto sostenendo, solo per darti un esempio su come gestire la soluzione in tempo reale.
Se vuoi scrivere il tipo di server http su cui amazon.com è ingegnerizzato, puoi guardare: libevent link
Se hai un po 'meno tempo a disposizione, ti suggerisco il framework twistato di Python. Usiamo Twisted sul mio lavoro per moltissime cose.
Il link viene eseguito su Twisted, che è il web in tempo reale.
Vedi qui: link
Leggi altre domande sui tag real-time scalability node.js