Blog

Perché WordPress non riesce a tenere aperto un websocket, e cosa fare invece

· Andrij Tkachenko · 5 min di lettura

La finestra di un sito web sul suo server, collegata da una linea a un cloud che tiene aperte le connessioni in tempo reale di cinque finestre del browser

Prima o poi un sito WordPress ha bisogno che qualcosa succeda in tempo reale: un nuovo messaggio che compare senza ricaricare la pagina, una notifica nel momento in cui arriva un ordine, il conteggio di chi è online, una chiamata che squilla. Sul web lo strumento per farlo è il websocket, una connessione tra il browser e un server che resta aperta, così il server può inviare qualcosa nell’istante in cui succede.

Poi arriva la sorpresa: WordPress non ha un server websocket, e l’hosting su cui gira non è in grado di tenerne uno. Questo articolo spiega perché, cosa fanno di solito i siti per aggirare il problema e cosa comporta gestire un server websocket tutto tuo.

WordPress risponde a una richiesta e si ferma

Ogni pagina di WordPress, ogni chiamata alla REST API e ogni richiesta admin-ajax funziona allo stesso modo. Il web server passa la richiesta a PHP, PHP carica WordPress con i suoi plugin e il tema, prepara la risposta, la invia e si ferma. La richiesta successiva riparte da zero.

È grazie a questo modello che WordPress gira quasi ovunque. Ed è sempre per questo che non può tenere aperto un websocket. Un websocket non è una singola richiesta ma una connessione che resta aperta finché resta aperta la pagina, spesso per ore. Mantenerla richiederebbe un processo PHP per ogni pagina aperta, che per la maggior parte del tempo non fa nulla, e un hosting dà a un sito solo pochi processi PHP, sufficienti per richieste che finiscono in una frazione di secondo. Una manciata di visitatori con una pagina aperta li occuperebbe tutti, e il sito smetterebbe di rispondere a chiunque altro.

I provider di hosting si proteggono da questo. Interrompono le richieste che durano troppo, spesso dopo 30-60 secondi, e sulla maggior parte dei piani non permettono a un sito di avviare un proprio processo in background, né di aprire una porta su cui ascolti. Anche dove l’hosting lo consente, il server che sta davanti a PHP, e qualsiasi proxy davanti a quel server, deve essere configurato per far passare un websocket.

Polling: chiedere di continuo

Il modo abituale per aggirarlo è il polling. La pagina chiede al server ogni pochi secondi: “c’è qualcosa di nuovo?” Di solito la risposta è no.

Ognuna di quelle domande è una richiesta WordPress completa: PHP si avvia, carica WordPress e i suoi plugin, interroga il database e risponde. Con 50 visitatori su una pagina che fa polling ogni 5 secondi, sono 10 richieste WordPress complete al secondo, ogni secondo, quasi sempre per niente. Chiedi meno spesso e il sito sembra lento, con un messaggio che impiega mezzo minuto a comparire. Chiedi più spesso e l’hosting comincia ad andare in affanno, o ti manda un avviso sull’uso delle risorse.

WordPress ne ha una sua versione, la Heartbeat API, che chiede ogni 15-60 secondi. Va bene per salvare le bozze e mostrare chi sta modificando un articolo. Per una chat o una chiamata è decisamente troppo lenta.

Il long polling e i server-sent events, in cui il server tiene aperta la richiesta finché non succede qualcosa, sembrano una soluzione. Su WordPress non lo sono: ogni richiesta in attesa occupa un processo PHP, e si va dritti contro lo stesso limite del websocket.

Un server websocket tutto tuo

La vera soluzione è un server fatto per tenere aperte molte connessioni, accanto a WordPress anziché al suo interno. Molti team ne costruiscono uno. Ecco cosa serve:

  • Un server dedicato, di solito un piccolo server virtuale con Node.js o un altro runtime pensato per le connessioni lunghe, con i suoi aggiornamenti e il suo monitoraggio.
  • Un certificato e un proxy, perché il browser possa collegarsi via wss:// sul tuo dominio.
  • Conoscere i tuoi utenti. Il server websocket non vede il login di WordPress, quindi il tuo sito deve dare a ogni pagina un token firmato, e il server deve verificarlo e decidere chi può entrare in quale canale.
  • Un modo perché WordPress possa inviare. Quando succede qualcosa in WordPress, un hook deve avvisare il server websocket, che poi lo inoltra ai browser giusti.
  • Più di uno, man mano che cresci. Un solo server è un unico punto in cui ogni connessione può cadere. Due o più hanno bisogno di un modo per scambiarsi i messaggi, e le pagine devono riconnettersi senza intoppi quando un server si riavvia.

Niente di tutto questo è esotico, ma è un secondo sistema da tenere in funzione accanto a WordPress, finché il sito ha funzioni in tempo reale. Per le chiamate è solo l’inizio: una chiamata ha bisogno anche di server STUN e TURN, e le chiamate di gruppo di media server, come spiega il nostro articolo su come funzionano le videochiamate di gruppo.

Oppure lascia che sia un cloud in tempo reale a tenere le connessioni

L’altra strada è un servizio in tempo reale gestito. I browser tengono le loro connessioni aperte verso il servizio, non verso il tuo hosting. Quando succede qualcosa sul tuo sito, WordPress invia una breve richiesta al servizio, e il servizio la consegna a ogni pagina che deve riceverla. Il tuo hosting risponde solo alle richieste normali, come ha sempre fatto.

WordPress resta il posto in cui vivono i tuoi dati. Il servizio trasporta solo gli eventi dal sito alle pagine e tra una pagina e l’altra, quindi non cambia nulla nel modo in cui il tuo sito salva articoli, utenti o ordini.

Come WordPlus Cloud lo fa per WordPress

WordPlus Cloud for WordPress è quel cloud, per ogni plugin di un sito WordPress:

  • Niente da gestire. I server in tempo reale, i relay per le chiamate, i media server e l’AI girano nel cloud. Al tuo sito basta un abbonamento, con un prezzo per sito e nessun limite di membri o messaggi.
  • Ogni plugin del sito può usarlo. Better Messages e Live Stream lo usano subito, senza configurare nulla. I plugin creati per il protocollo Pusher si collegano con i nostri host e le chiavi del tuo sito, e qualsiasi altro plugin, tema o codice personalizzato si collega tramite la nostra API per sviluppatori.
  • I tuoi dati restano in WordPress. Conversazioni, membri e file restano nel tuo database. I messaggi attraversano il cloud sigillati con una chiave che custodisce il tuo sito, così li inoltriamo senza leggerli.
  • Non solo websocket. Lo stesso abbonamento porta chiamate che si collegano sempre, chiamate di gruppo, notifiche push su browser e telefoni, live streaming, app mobili tutte tue e AI, sulla stessa connessione.

Una pagina tiene una sola connessione, condivisa da tutti i plugin del sito, che passa a un altro server senza cadere quando uno si riavvia. Il tuo hosting torna a fare ciò che sa fare bene: rispondere alle richieste.

Scopri WordPlus Cloud for WordPress, o i prezzi per il tuo numero di siti.