Con queste impostazioni l’esperienza utente era migliore. Sì, si sono verificati diversi “colli di bottiglia” e nel mio Chrome Inspector sono stati registrati numerosi errori 429. Il carico sulla CPU era basso. Tuttavia, va detto che si trattava di una partita casalinga piuttosto tranquilla (molti membri attivi erano presenti, ma non stavano chattando).
Non riesco a indicare quali parametri modificare, ma, dalla mia esperienza piuttosto soggettiva:
La funzionalità relativa al codice è ancora eccessivamente protettiva riguardo al carico del server. Forse si potrebbe permettere un livello di stress del server leggermente più alto.
Quando il client riduce la frequenza, il ritardo è troppo lungo dal punto di vista dell’esperienza utente. Il gioco continua e in un minuto può succedere molto. La chat si desincronizza, con gli utenti che fanno riferimento a eventi diversi del gioco. (Questo aggrava il problema dei diversi ritardi temporali tra streaming in tempo reale, TV via cavo, IPTV e il buffer di Chromecast di 20 secondi, ecc.)
L’utente vede solo che la chat si è bloccata, ma non riceve alcuna indicazione che il sito sia ancora online e attivo. È più probabile che ricarichi la pagina o compia altre azioni, il che aumenta ulteriormente il carico.
Solo per escludere alcune possibilità, ho aggiornato il server a 8 vCore e 32 GB di RAM. Ho impostato i buffer del database a 16 GB e gli Unicorn a 16. Gli altri parametri sono stati riportati ai valori predefiniti.
Purtroppo, l’aggiornamento non ha fatto granché. Le discussioni rapide si bloccano costantemente, anche con un’attività mediocre.
Le prestazioni sono miserabili al giorno d’oggi. Immagino di dover iniziare a valutare strumenti come Prometheus. Sono al 95% certo che le prestazioni del software si siano seriamente regredite dalla versione 2.3.
Il commento di mio fratello @Iceman è stato in gran parte ignorato a settembre. Egli riferisce che i colli di bottiglia si verificano indipendentemente dall’hardware utilizzato?
Sospetto che tu stia riscontrando un collo di bottiglia su Redis, ma come ho detto molte volte, possiamo esserne certi solo se raccogli quelle statistiche. Senza di esse, potremmo anche affidarci all’astrologia.
Se il mio sospetto è corretto, spiegherà anche perché aggiungere più core lenti e RAM non fa alcuna differenza: poiché Redis è single-thread, l’unica via per scalare è ottenere core ad alte prestazioni.
Entro la fine del mese rilasceremo una nuova immagine con il rilascio definitivo della versione 2.6, che include Redis 6 e nuove variabili app.yml per sfruttarle al meglio. Fammi sapere se vuoi testarla prima; posso fornirti le istruzioni necessarie.
Ho appena notato questo in un argomento chiuso. @codinghorror - non è corretto. Ciò che l’utente finale ottiene realmente in una situazione di alto carico è:
Una notifica che indica di essere stato disconnesso
Verrà reindirizzato alla pagina indice del sito
La pagina indice mostrerà la notifica a banner relativa all’alto carico
Tuttavia, l’utente non è realmente disconnesso. Di solito, quando si torna all’argomento attivo, il sito riprende a funzionare normalmente.
Ancora una volta, non abbiamo clienti che segnalano questo comportamento (su migliaia di utenti, molti dei quali gestiscono siti molto più trafficati del vostro), quindi un’ulteriore discussione in questo momento è sostanzialmente inutile: non abbiamo visibilità su quale strana configurazione o problema di prestazioni hardware possiate avere dalla vostra parte.
In futuro, speriamo che la situazione cambi e che possiamo avere una migliore visibilità sul problema effettivo.
Il comportamento dovrebbe essere che rimangano nella pagina dell’argomento e venga loro mostrata una visualizzazione per utenti non registrati, anziché essere reindirizzati alla home page.
Quindi, se Redis è il collo di bottiglia, come lo scaleresti orizzontalmente?
Mi rimane ancora un mistero cosa sia cambiato rispetto alla scorsa stagione. Non vedo una crescita organica significativa o un aumento della popolarità delle chat di gioco. Eppure, la nostra capacità di gestire il servizio è diminuita drasticamente, causando problemi anche nelle partite più tranquille.
Finché non potrai raccogliere metriche sulla tua istanza storica di Discourse e confrontarle con quelle raccolte sulla tua installazione attuale, mantenendo l’identico hardware, questo rimarrà un mistero.
La differenza potrebbe essere semplicemente che il tuo provider VPS ti ha spostato da una macchina fisica a un’altra, che hai acquisito un “vicino rumoroso”, o che il tuo VPS ora ospita in media 17 servizi invece di 13 per macchina.
Ti chiedo gentilmente di non fare supposizioni sull’escalation del problema verso il provider VPS. UpCloud è uno dei migliori sul mercato e hanno già verificato la loro parte per eventuali anomalie. Pubblicizzano sul nostro sito e non sarebbe una buona pubblicità se il sito risultasse instabile
Tuttavia, non ci sono dati storici e, a essere onesti, non stavo prestando così tanto attenzione perché tutto funzionava perfettamente, fino a quando non si sono tenute le prime partite di esibizione ad agosto. È ovvio che i comportamenti umani sono cambiati grazie al COVID, e chissà cos’altro. Non riesco però a vederlo nelle metriche del nostro sito o del server.
Ma questo è materiale di test eccellente. Ho appena fornito a @riking alcuni screenshot di ciò che accade quando si attiva il sovraccarico del server. Immagino che voi non lo vediate molto spesso.
Nota che nessuno è in disaccordo con te — stiamo solo sottolineando che un medico può fare solo un certo sforzo per diagnosticare un paziente quando è limitato a vederlo attraverso una videocamera su Internet..
Volevo solo dire che è esattamente ciò che ho sperimentato io quando ho configurato per la prima volta il mio sito (quindi non è un problema unico del tuo).
Ecco un thread che ho creato a quel tempo:
Questo è stato ciò che mi ha spinto a passare a opzioni CPU/RAM più elevate, come descritto qui:
Purtroppo, non ho ancora avuto la possibilità di migrare correttamente da Digital Ocean a Hetzner come avevo pianificato (ho iniziato un nuovo lavoro). Lo farò non appena avrò l’opportunità questo mese.
L’esperienza dell’utente finale, sia che venga espulso dalla discussione o che vi rimanga (con il messaggio di disconnessione), sembrava dipendere dal carico. (Più utenti venivano reindirizzati alla pagina principale dopo un gol).
Non ho conoscenze tecniche sufficienti per essere di grande aiuto, ma ho pensato potesse essere utile sapere che un sito sportivo con picchi di chat simili ha riscontrato problemi analoghi. Nel mio caso (sito più piccolo e giovane), il problema è stato risolto con un ulteriore aggiornamento del server.
Ho installato un nuovo ambiente a 2 container su 2 server VPS (web_only, data).
Sorprendentemente (per me), il server web_only è sotto forte carico, mentre il data è relativamente poco sollecitato. Entrambi eseguono un piano UpCloud.com da 4 vCore e 8 GB di RAM.
Ho aggiornato il server web_only a un piano UpCloud.com da 6 vCore e 16 GB di RAM. Ho aumentato il numero di Unicorn a 18.
Tuttavia, continuiamo a incontrare vari limiti 429. La modalità system under high load non si è attivata.
La stagione di hockey è stata rovinata dal COVID, e ora stanno giocando alcune partite casuali senza pubblico. Dato che abbiamo dei crediti di hosting con UpCloud.com, stiamo cercando di migliorare l’esperienza utilizzando ciò che abbiamo a disposizione. Attualmente stiamo eseguendo 6x vCore 16GB per web_only e 4x vCore 8GB per data, unicorni a 18.
Abbiamo nuovamente disabilitato il limitatore di richieste…
DISCOURSE_MAX_REQS_PER_IP_MODE: none
…il che aiuta, ma riceviamo ancora errori 429 dalle POLL, che causano lunghi ritardi/block per l’utente finale. Continueremo a ottimizzare aumentando il valore di DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS.
Non dovrebbe essere necessario: saremmo felici di ospitarti in modo da poter capire perché continui a incontrare questo problema, nonostante il tuo traffico sia così basso.
Forse è così, ma vorremmo essere leggermente meno protettivi verso il server, poiché i picchi di attività naturali sono molto brevi e generalmente si stabilizzano entro un minuto circa. Quindi, alzare leggermente le soglie potrebbe migliorare l’esperienza utente, in attesa del trasferimento.
I giochi sono stati scarsi (grazie al COVID), quindi abbiamo avuto pochissime opportunità di misurare e sperimentare con questo.
Abbiamo scoperto che, anche con le nostre risorse hardware migliorate (6+4 vCore e 16+8 GB di RAM), anche una folla moderatamente attiva è riuscita a generare errori 429 sui client. Abbiamo osservato questo durante le partite della U20 WC, che hanno attirato circa il 50% del nostro pubblico abituale per le chat.
Dopo aver misurato, provato e sbagliato, abbiamo stabilito le seguenti ottimizzazioni:
Questo sembra eliminare l’80% degli errori 429, consentendo un’esperienza relativamente fluida per la maggior parte degli utenti.
Il prossimo passo sarebbe stato acquistare risorse hardware di tipo diverso, utilizzando server dedicati per la velocità single-thread o passando a un provider VPS che offra piani con migliaia di vCore. Per noi, tuttavia, il prossimo passo è lavorare con il team di hosting di Discourse, come ha accennato in precedenza @sam.
Speriamo che queste ottimizzazioni possano essere utili per @iceman, @alec o chiunque altro. Assicuratevi di monitorare l’utilizzo della CPU e le code. Inoltre, quanto ho imparato da questa esperienza è che 2 container sono di gran lunga migliori di uno: le ottimizzazioni possono essere applicate con tempi di inattività quasi nulli e le risorse hardware possono essere sfruttate in modo più granulare.
Sono ancora interessato a eventuali nuove ottimizzazioni o scoperte che possano contribuire a migliorare le prestazioni e l’esperienza utente per discussioni dinamiche guidate da eventi del mondo reale.
