Il php è scalabile con polling lungo ajax inverso?

Question

Sto lavorando a un sito Web che visualizza alcuni dati dal DB che cambiano frequentemente (stato di una coda e conversazione in chat). La mia attuale configurazione è Apache/PHP/MySQL. Ovviamente vorrei evitare di eseguire il polling del server ogni x secondi poiché questo non si adatta bene. Mi piacerebbe fare un reverse polling ajax lungo, tuttavia, ho letto che Apache non funziona bene con questo poiché esaurisce rapidamente i thread di lavoro. Esistono molti altri server Web che risolvono questo problema: nginx, tornado, ecc. Tuttavia, il mio problema è che PHP è l'UNICO linguaggio di scripting lato server che conosco. Inoltre ho già scritto alcuni script PHP, quindi mi piacerebbe tenerli se posso. Sto bene con il cambio server fino a quando posso ancora usare PHP.

Ma dopo aver fatto qualche ricerca in più, ho letto che le persone dicono che PHP (PHP-FPM?) Crea anche un processo per ogni richiesta fatta, il che significa che se avrò centinaia/migliaia di connessioni aperte, ci saranno centinaia/migliaia di processi, che saranno anch'essi un problema.

Posso concludere che non esistono buoni modi scalabili per realizzare siti Web di polling lunghi utilizzando PHP? Dovrei abbandonare PHP e imparare un altro linguaggio di scripting del server? Posso continuare a sviluppare lunghi sondaggi usando la mia attuale configurazione (Apache/PHP) per ora, ma non voglio che la scelta del linguaggio di scripting ponga limiti alla scalabilità del mio sistema durante la distribuzione. Quindi cosa dovrei fare? Non ho molta esperienza con la programmazione web, quindi se qualche guru là fuori può darmi dei consigli, lo apprezzerei! Grazie!

Answer 1

PHP eseguito in modalità php-fpm avrà ancora dei limiti, specialmente se il tuo codice sta consumando molta memoria. Non sarai in grado di eseguire migliaia di processi paralleli senza memoria disponibile. Ma di solito è più veloce di mod_php, e almeno la richiesta HTTP che non ha bisogno di PHP viene gestita dal server web, e se quel server web è nginx avrai molte più richieste HTTP disponibili in parallelo.

Con php-fpm avrete anche una coda di richieste in attesa, che può essere utile in caso di un traffico temporaneo di grandi dimensioni, poiché almeno le richieste sono in coda, non rifiutate.

Ora le lunghe operazioni di polling sono OK con nginx (o altri, questo è un esempio), ma non con PHP. PHP non è costruito per essere un server con un tempo di esecuzione limitato, ogni richiesta è un nuovo processo, non è davvero la scelta giusta per una cosa KeepAlive. Ma "Divide ut regnes" (divide e regola). Le tue lunghe attività di polling potrebbero essere eseguite vicino all'applicazione PHP, ma senza la tua applicazione PHP.

Ad esempio, guarda il jappix project, questo è un progetto PHP. Ma devi mettere da qualche parte un server XMPP (come ejabberd) e un server BOSH con nginx come proxy sulla porta 80 a quel server BOSH (quindi hai il protocollo di chat xmpp sulla porta 80, via nginx e ejabberd, e niente su il lato PHP per quello). Il problema è quindi connettere l'autenticazione, l'identificazione e simili dell'applicazione, e ciò dovrà essere fatto estendendo la configurazione del server XMPP (in modo che utilizzi lo stesso server LDAP della tua app PHP, ad esempio).

Il secondo problema di polling lungo è lo stato di una coda. Potresti trovare alcune estensioni XMPP per questo, forse. Oppure è possibile eseguire regolarmente query ajax sulla coda. Una delle tecniche utili per evitare il gran numero di richieste Ajax sulla tua applicazione PHP è di riprogrammare il prossimo controllo ajax sul callback ajax del controllo, basato sui numeri di Fibonacci (è un esempio). Quindi la prima volta che la prossima chiamata ajax sarà programmata 1 minuto dopo, la prossima volta 2 minuti, poi 3m, 5m, 8m, 13m, 21m, 34m, 55m, 89m, 144m, ecc. L'idea è che forse è importante controllare nuovi messaggi in arrivo 1 minuto dopo il caricamento di una pagina. Poiché l'utente sta ancora leggendo la stessa pagina (o bevendo un caffè, parlando con un amico, andando in vacanza senza spegnere il suo computer, ecc.), Possiamo ritardare sempre di più i prossimi controlli.È un modo di presumere che l'utente non sia realmente attivo. Si noti che è possibile rilevare l'attività dell'utente con altri mezzi e modificare la riprogrammazione.

Answer 2

PHP non è adatto a lunghe tecnologie di polling, comet e reverse ajax. Dovresti usare Node.js