Grazie. Probabilmente mi hai risparmiato molte ore di debug, tentativi ed errori.
Questa differenza di comportamento mi ha portato a concludere che si tratti di una correlazione applicativa derivante da un problema di tipo FrontEnd che “crasha” l’app (non essendo il FrontEnd il mio ambito di competenza, a differenza del BackEnd) e dalle operazioni in corso, con pubblicazioni e utenti che rimangono su un argomento in attesa che si “aggiorni da solo” con decine di messaggi in un singolo minuto.
Per riassumere questa mega-frase: la tua conclusione è che il “soffocamento” delle discussioni in tempo reale rapide sia un problema front-end?
Non sono arrivato molto lontano nella nostra analisi, ma ho osservato che il carico della CPU era ben lontano dal massimo, intorno al 25% circa. Nel corso degli anni abbiamo raggiunto il 100% della CPU molte volte, ma non è stato questo il caso nell’ultimo incidente dello scorso sabato. Avevamo solo circa 150 utenti contemporanei.
Ciò che mi ha portato a sospettare il back-end è il fatto che gestiamo queste chat di gioco da anni e non ho mai visto questo “soffocamento” prima. Nel corso degli anni il database è cresciuto e ora superiamo gli 800.000 post.
Quando hai visto per la prima volta questo problema? Potrebbe essere un regresso con l’ultimo aggiornamento importante? Il nostro sito e le prestazioni erano perfetti in primavera e non siamo cresciuti molto durante l’estate.
Babel è un plugin spettacolarmente inefficiente, quindi se lo stai utilizzando, avrai dei problemi… specialmente sotto carichi di utenti attivi simultaneamente elevati.
Abbiamo ora un TODO nel nostro backlog per migliorare le prestazioni nei casi in cui 1000 persone stanno visualizzando lo stesso argomento e una persona pubblica un messaggio.
Come è progettato oggi, inviamo a tutte le 1000 persone il messaggio “Ciao, c’è un nuovo post per questo argomento”, dopodiché tutte le 1000 si rivolgono al server (per lo più contemporaneamente) chiedendo… “Ehi, qual è questo nuovo argomento di cui stai parlando?”
Valuteremo di limitare in modo minimo e più pulito questa situazione, in modo che i client non sovraccarichino il server, ma ci sono diverse ottimizzazioni che possiamo apportare per questo caso anomalo.
Ottima notizia che questo sia sotto la tua attenzione. Puoi confermare se si è verificato un regresso rispetto alla primavera scorsa?
Il nostro campionato locale di hockey cerca di iniziare le partite il 1° ottobre. Questo significa che il nostro sito può generare picchi di traffico in tempo reale su base settimanale, nel caso in cui tu abbia bisogno o voglia studiare il comportamento mentre si verifica in un ambiente reale (non simulato).
Invia un messaggio privato se sei interessato. Siamo felici di supportarti.
Dal punto di vista dell’esperienza utente, l’utente finale dovrebbe in qualche modo sapere che la discussione è attiva, anche quando il sistema inizia a rallentare. Questo potrebbe prevenire inutili aggiornamenti della pagina nel browser.
La prima partita è appena terminata e abbiamo sicuramente un problema che non avevamo a marzo. La causa è ancora sconosciuta.
La chat di gioco si blocca sul frontend, mentre il carico del server dovrebbe essere ben al di sotto del 100%.
Uno dei nostri utenti ha notato diversi risposte server 429 durante i blocchi, ma non posso dire se questo sia “normale” poiché non abbiamo mai effettuato tale controllo durante le partite in passato.
Ne ho visto uno mentre investigavo su un ‘500’ totalmente irrilevante
Il server non era affatto occupato, ma stavo modificando una configurazione front nginx (http2)
Infatti. In un arco di tempo di un paio d’ore ci sono state circa 900 risposte reazionarie. @ljpp ha numeri più precisi sugli utenti, ma stiamo parlando di centinaia di utenti che navigavano l’argomento in qualsiasi momento durante la partita.
Stranamente, questo non colpisce tutti gli utenti. Io, ad esempio, non ho riscontrato alcun problema su nessun dispositivo. Ma, secondo le segnalazioni, il fenomeno è abbastanza diffuso.
Non è così ovvio accorgersene, specialmente se non si presta molta attenzione.
Innanzitutto, si verifica una pausa di 30-60 secondi senza risposte. Non sembra che ci sia nulla di “sbagliato”, è solo silenzio. Puoi persino scrivere il tuo post. Poi, all’improvviso, ricevi decine di messaggi in un attimo e ti rendi conto di essere rimasto indietro. Ho osservato questo comportamento su iOS Safari e Android Chrome.
Le nostre chat di gioco in tempo reale sono vivaci, ma non in casi estremi. Ieri abbiamo avuto 972 messaggi nell’arco di circa 3 ore.
La prossima chat di gioco si terrà oggi alle 14:00 UTC. A causa della pandemia, mi aspetto numeri simili, anche se si tratta di una partita casalinga.
Non stai cercando di forzare un caso d’uso di chat su una piattaforma forum?
Perché non integrare invece un servizio di chat come Mattermost o Discord nell’interfaccia del tuo sito Discourse, lasciando a questo mezzo la discussione relativa al gioco?
Potresti trovare un altro modo per trattare il gioco in un argomento del forum, come discussioni pre-partita o post-partita, dove il carico di utilizzo potrebbe essere meno intenso ma contenere comunque informazioni riassuntive utili che molti utenti potrebbero voler recuperare in un secondo momento.
Inoltre, non vedo il vantaggio di archiviare un enorme volume di chat estemporanee su un forum. Qualcuno le rileggerà davvero? Sono utili?
Beh, lui usa la parola “chat” per questo, ma secondo l’utente la sua configurazione di Discourse non può gestire “972 post in circa 3 ore” in un argomento. A mio avviso dovrebbe essere in grado, anche un semplice phpBB può gestire molte volte più post in 3 ore di così.
Quindi un post ogni 10 secondi? Di per sé non sembra irragionevole. Ma poi crei un argomento di 1000 post, con centinaia di utenti che partecipano e, in più, si verificano picchi di pubblicazioni. Capisco la sfida!
Ma qual è il vero colpevole o collo di bottiglia qui? Il numero di utenti partecipanti, o un post ogni 10 secondi, o il rendering del contenuto modificato per (troppi) utenti anonimi/non anonimi, o il numero di connessioni necessarie per servire troppi utenti connessi?
Riceverà lo stesso problema se solo 2 utenti producessero la stessa quantità di post in un argomento nello stesso lasso di tempo?
Anche con soli 972 utenti connessi che fanno un solo post in quell’argomento, Discourse non è in grado di gestirlo? E se sì, perché? Discourse è davvero la scelta giusta solo per comunità molto piccole con un basso numero di utenti connessi simultaneamente?
Mi chiedo solo, dato che abbiamo già fino a 400 utenti connessi simultaneamente in alcuni momenti, che producono fino a 3000 post al giorno… finora nessun problema.
È evidente che è necessario tenere conto delle specifiche del server e del numero di unicorni in esecuzione, altrimenti i risultati di questi scenari di stress sono meno significativi.
Blenderartists (@bartv), credo, abbia un server da 64 GB e circa una dozzina di unicorni in esecuzione? Un vero mostro
Assolutamente, al momento siamo su 8 GB / 4 vCPU con DO e non stiamo riscontrando problemi. Quindi, se la soluzione a questo è semplicemente aggiungere risorse (RAM e CPU), per me va bene. Al picco, da quando abbiamo ripreso con Discourse, abbiamo avuto circa 2000 visitatori contemporanei su un post diventato virale e il carico era appena sopra 1, la CPU era al 60-70%. In media, con circa 200-250 utenti contemporanei connessi, la CPU è a riposo intorno al 15%-20% al momento.
Potresti fare questa osservazione, ma mi dispiace molto l’idea di frammentare le conversazioni su due piattaforme diverse. La real-timeità è effettivamente una delle funzionalità principali di Discourse, apprezzata dagli utenti finali. Le nostre conversazioni durante il gioco sono un grande successo e una parte importante della cultura della comunità.
Tieni presente che li stiamo gestendo da quattro anni e questo è un nuovo problema che stiamo affrontando. Quindi centinaia di partite sono andate a buon fine, senza “forzare” nulla.
Uno dei nostri membri esperti aveva una teoria: potremmo aver raggiunto i limiti globali di Discourse e forse CloudFlare ha un impatto.
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: numero di richieste per IP al minuto (il valore predefinito è 200)
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: numero di richieste per IP ogni 10 secondi (il valore predefinito è 50)
La prossima partita è tra un’ora e proveremo a disabilitare la cache di CF.
Tieni presente che stiamo utilizzando CloudFlare da 4 anni, anche se in genere non è consigliato qui. Ci sono stati solo uno o due problemi lungo il percorso, tra cui Brotli e un modello non aggiornato.
