Nota: Non sono certo che si tratti di un bug di Discourse. Ho cercato di raccogliere le prove necessarie e finora non ho trovato nulla che indichi problemi nella nostra infrastruttura o configurazione. La nostra configurazione è il più possibile “vanilla” su Tappara.co
Fenomeno osservato:
I topic di discussione rapida simili a chat smettono di aggiornarsi automaticamente. Dopo un ritardo di 30-180 secondi, l’aggiornamento di solito riprende, rivelando i post pubblicati durante il blocco.
Cosa sappiamo finora
Non abbiamo riscontrato questo problema nella stagione precedente; l’ultima partita si è giocata a marzo.
Utilizziamo il ramo stabile e abbiamo effettuato l’ultimo aggiornamento maggiore ad agosto.
Il problema è stato segnalato immediatamente durante le prime partite amichevoli, con traffico/attività moderato.
Questo colpisce iOS e Chrome su Android, ma è molto meno frequente su Chromebook.
Mentre scrivo, vedo blocchi sul mio telefono Android, mentre la discussione scorre come previsto sul mio Chromebook. Due dispositivi diversi nella stessa rete.
L’esperienza varia per utente/client. Diversi utenti riportano i blocchi in momenti diversi. Nel complesso, abbiamo registrato circa 300 messaggi in circa 30 minuti e gli utenti hanno segnalato decine di blocchi. Nella maggior parte dei casi, i blocchi sembrano correlarsi con eventi di gioco (gol, penalità).
Cose che ho provato per escludere cause
CloudFlare – abbiamo giocato una partita senza caching di CF, ma il problema è persistito.
Sovraccarico della CPU – l’utilizzo della CPU è ben entro i limiti, solitamente intorno al 20-30%.
Esaurimento del disco – l’I/O del disco sembra essere ben entro i limiti. Utilizziamo SSD MaxIOPS di UpCloud.
Altre informazioni
Ho tenuto aperto l’ispettore di Chrome durante la partita e sono stati registrati alcuni errori 429, ma per me non erano correlati ai blocchi.
Gli utenti finali non ricevono le notifiche relative agli errori 429 (rallentamento) o al carico estremo. L’aggiornamento semplicemente si blocca e poi riprende. Il limitatore di velocità è cambiato recentemente? Ho l’impressione che i limiti di velocità dovrebbero attivare un avviso nell’interfaccia utente?
Un problema davvero spiacevole, che danneggia molto le chat di gioco in tempo reale. Gestiamo queste sessioni da anni e non ho mai visto nulla del genere prima d’ora.
Quando i tuoi web workers iniziano a essere sovraccarichi di richieste, introduciamo ritardi nella connessione persistente che aggiorna automaticamente l’argomento quando arrivano nuovi post.
Se vedi questo messaggio e un utilizzo della CPU basso come riportato, aumenta il numero di worker unicorn e questo dovrebbe risolvere il problema.
Siamo già a 11 Unicorni, su un VPS a 6 core. Come detto, questo non si è mai verificato nella stagione precedente, l’ultima volta a marzo. Ora si verifica anche con traffico moderato. Inoltre, questo succede molto più spesso su dispositivi mobili, specialmente su Android Chrome, rispetto ai desktop.
Inoltre, siamo riusciti a saturare la CPU in passato (alla scadenza del termine per i trasferimenti).
Ho perso una partita monitorando e intervenendo sul server. Abbiamo raddoppiato i parametri web.ratelimited, ma ciò non ha risolto il problema.
Inspector rileva diversi errori 429:
1. URL della richiesta:
https://tappara.co/message-bus/3ed86765a67f4c31ba4053a0352ecaf5/poll
2. Metodo della richiesta:
POST
3. Codice di stato:
429
La prossima partita è domani, quindi posso provare con gli Unicorni. Fino a che punto possiamo spingerci? È cambiato qualcosa con l’ultimo aggiornamento maggiore?
Modifica:
Ho dato un’occhiata alle statistiche e finora la nostra attività è stata inferiore rispetto a quella osservata in primavera (visualizzazioni di pagina, utenti). Il numero di post per la chat della partita è identico (circa 900-1000 ogni 3 ore).
Quindi, per una ragione sconosciuta, al momento non siamo in grado di servire lo stesso pubblico che avevamo a marzo.
Ottimo! Potresti confermare se c’è stato un recente cambiamento o regressione (negli ultimi 6 mesi) che ha causato questo?
Nel frattempo, penso che aumenterò la potenza delle unicorni per la partita di stasera e vedrò cosa succede. Se possiamo supportarvi in qualche modo, fatecelo sapere.
@falco Il numero di unicorni non è di certo la chiave. Li ho aumentati a 15 per la partita di stasera. L’argomento della partita era tranquillo, solo 700 messaggi, ma si sono verificati continui blocchi. Il carico della CPU era lieve, tra il 5% e il 25%.
Più investigo su questo problema, più sembra trattarsi di un bug e di una regressione, ma le mie competenze non sono sufficienti per individuarne la causa.
Credo ci sia un bug nel client che sostanzialmente blocca gli aggiornamenti dopo il primo errore. Il mio sospetto è che tu stia riscontrando questo problema perché i tuoi utenti stanno venendo limitati in termini di richieste.
Questa settimana indagherò su come rendere il client più robusto. Come ho detto prima, si tratta di codice delicato e richiederà del tempo.
La risoluzione di questo problema mi ha portato a riflettere sull’esperienza utente (UX) di una discussione quasi in tempo reale in generale. Molte comunità affrontano eventi della vita reale, che naturalmente “spingono” la discussione verso una conversazione rapida simile a quella di una chat. Può trattarsi del mercato azionario, del lancio di un importante prodotto o di un gioco (eSport o fisico)… ne esistono di tutti i tipi.
Tuttavia, in questo tipo di cultura di discussione simile a una chat, la qualità dei post varia notevolmente. D’altro canto, i post tendono naturalmente a verificarsi esattamente nello stesso momento. Immaginiamo che stia andando in corso una grande partita di hockey e qualcuno segna un gol.
Una grande parte dei post sono semplici reazioni emotive, esultanze o lamenti.
“Goooool!!! Sì, baby”
Alcuni sono informativi:
“Crosby segna, 1-0 per i Pens”
Una piccola minoranza si impegna a fornire un’analisi:
“Crosby segna un gol in contropiede, dopo un errore di pressing da parte dei Caps, ma sembrava molto un fuorigioco. L’allenatore dei Caps dovrebbe contestare la decisione.”
Ora, dato che Discourse è una piattaforma veloce (quasi in tempo reale), ciò significa che anche quando tutto funziona senza intoppi, riceverai diverse dozzine di post virtualmente nello stesso istante. Per il lettore, specialmente per chi non sta guardando la partita ma la segue nella chat, questo rappresenta una sfida UX: è difficile individuare i post informativi in mezzo alle esultanze e ai lamenti. Nei nostri forum dedicati alle chat delle partite, ci viene spesso chiesto “Com’è il punteggio?”, poiché chi guarda la partita dimentica di segnalare l’ovvio o le informazioni si perdono nel flusso di messaggi.
Non so come funzionerebbe nella vita reale, ma sarebbe interessante testare se gli amministratori possano impostare il ritmo della discussione. Ad esempio, un post al secondo. Tutti i post verrebbero messi in coda, ma pubblicati sul sito con un ritmo definito. Se un gol genera 20 post di reazione, non apparirebbero tutti nello stesso momento nel topic, ma nell’arco di una finestra temporale di 20 secondi. Non sarebbe forse più facile seguire la discussione e cogliere le informazioni rilevanti?
Questo potrebbe naturalmente portare ad altri problemi: se il ritmo dei nuovi messaggi superasse costantemente il ritmo di pubblicazione, si formerebbe una coda di lunghezza crescente e la chat inizierebbe a rimanere indietro rispetto alla realtà.
Non sono sicuro che abbiate colto l’idea, e nemmeno io sono certo che l’idea sia buona. Il punto fondamentale è che l’UX della chat in tempo reale è un argomento interessante e potrebbe avere potenziale per ulteriori sviluppi. So bene che l’obiettivo principale di Discourse non è creare una piattaforma di chat: esistono altri software per quello. Tuttavia, queste situazioni accadono naturalmente.
Mi piace quest’idea, ma servirebbe una sorta di shadow banning inverso in modo che le persone vedano sempre immediatamente i propri post. Altrimenti potrebbero pubblicare due o addirittura tre volte, pensando che il forum non funzioni.
Assicura che non sovraccarichiamo un server se 1000 persone stanno visualizzando un singolo argomento e vengono pubblicati nuovi messaggi.
In questi casi, il client si comporta ora in modo molto più pulito.
Anticipando la domanda di @ljpp, sono ancora indeciso sul backport: questa modifica comporta cambiamenti nell’API ed è piuttosto significativa. Se decidiamo di procedere con il backport… probabilmente ci vorranno alcune settimane. Devo osservare il comportamento in produzione sotto carico e, dato che abbiamo così tanto margine nella nostra infrastruttura di hosting, eventi come questo sono così rari che ci vorrà del tempo per verificarli.
Proviamo a verificare se disabilitare il limitatore di richieste sia una soluzione praticabile.
Se lo è: la prossima versione stabile non è molto lontana, presumo.
Se non lo è, esamineremo il canale Beta. Dovremo verificare che le nostre personalizzazioni dell’interfaccia non vengano compromesse dall’aggiornamento.
Abbiamo altre community con discussioni simili a quelle di una chat che utilizzano rami edge?
Capisco il ragionamento per cui questo potrebbe non essere un candidato per il backport. Ho appena disabilitato il nostro ratelimiter e domani si gioca la prossima partita, quindi avremo un’idea approssimativa se possa fungere da soluzione pratica per le istanze che non vogliono passare alla versione beta.
Stiamo decisamente considerando di passare al ramo beta per i prossimi mesi. Tuttavia, ci sono anche altre preoccupazioni: @rizka ha segnalato che la traduzione FI è in ritardo (ma potrebbe riuscire a lavorarci più avanti questa settimana).
Purtroppo disabilitare il ratelimiter non ha affatto aiutato. È stata una partita noiosa e 83 utenti hanno pubblicato solo 580 messaggi. Durante la partita sono stati segnalati diversi blocchi.
Esistono eventuali hack o soluzioni alternative da provare, in attesa dell’aggiornamento a una release edge?
I “freeze” sono un bug del client: semplicemente non reagiva correttamente alle condizioni di errore. Anche un solo errore di limite di richiesta e sei fuori gioco sulla versione stabile.
Non riesco a pensare a soluzioni alternative se non aggiornare alla versione beta (ne stiamo rilasciando una nuova domani).
Uno dei nostri membri orientati allo sviluppo ha proposto di modificare la seguente variabile. Cosa ne pensi: la vedi come una possibile soluzione alternativa?
Ciò ha ridotto significativamente il numero di rallentamenti osservati, ma non ha risolto il problema. Il carico della CPU è aumentato, oscillando intorno al 55% durante gli eventi principali del gioco.
Sono state apportate recenti modifiche per aiutare con i “freeze”: se il server è sovraccarico, il client si fermerà e attenderà.
Tuttavia, la soluzione definitiva potrebbe essere quella di ottenere un server più potente ed eseguire più worker Unicorn. Consulta lo script discourse-setup per le nostre raccomandazioni sulla capacità del server in relazione al numero di worker.
Ne dubito… il problema sotto un elevato carico di risposte è che, prima del nuovo design, potevamo generare un flood che avrebbe attivato i limiti di velocità a causa di max_reqs_per_ip_per_10_seconds e simili. Sarebbero necessarie risorse enormi per gestire il carico.
Pensaci.
30 utenti pubblicano una risposta entro 10 secondi
100 persone stanno visualizzando l’argomento.
Il server deve essere in grado di gestire 3000 richieste GET per richiedere un singolo post alla volta.
Se QUALSIASI di queste richieste fallisce per qualsiasi motivo, l’interfaccia si bloccherebbe e apparirebbe rotta.
Il nuovo design risolve questo problema in modo molto pulito: le richieste si riducono in modo ordinato, vengono raggruppate se si crea un accumulo, l’interfaccia non si blocca e così via.
Non riesco a vedere come il vecchio design possa scalare per 100 utenti contemporanei e 30 risposte in 10 secondi.
Vedo invece che il design attuale, revisionato, funziona perfettamente con 1000 utenti contemporanei che visualizzano un argomento con 30 risposte in 10 secondi.
.