Ieri abbiamo implementato un significativo miglioramento delle prestazioni per i siti con attività di pubblicazione attiva e molti utenti; questo dovrebbe aiutare molto anche sul tuo sito.
Molto bene, daremo un’occhiata e potremmo testarlo.
Beh, ogni partita è un caso a sé. Con la situazione legata al COVID (arena vuota) e un calendario delle partite quasi casuale, il comportamento del pubblico è impossibile da prevedere o confrontare con i dati storici.
Basandomi su questa singola partita, non posso affermare che questa modifica ci abbia portato un miglioramento significativo.
Il primo periodo è stato tranquillo e normale, ma gli eventi accaduti durante il secondo hanno causato un picco nei messaggi e un aumento dei lurker. Circa il 60% dei nostri utenti ha segnalato di aver sperimentato blocchi.
Nella configurazione con due server, web_only è l’unico che segnala un elevato utilizzo della CPU e un alto load average.
La modalità carico estremo / sola lettura non è stata attivata, il che è positivo poiché rappresenta l’esperienza utente più problematica. Nel complesso, il pubblico ha imparato rapidamente a visitare la pagina principale e tornare per riprendere la discussione, il che genera ulteriore carico sui server. Se solo l’utente finale potesse essere informato in qualche modo di essere sottoposto a throttling, sarebbe più propenso ad aspettare davvero un minuto.
Rapporto di progresso dalle conversazioni private: l’esperienza è stata migliorata impostando DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS a 4, e stiamo pianificando alcune modifiche al core per migliorare il comportamento del rate limiting del message bus.
Dato che sperimentiamo alcune similitudini con la situazione di @ljpp, sebbene in misura significativamente minore (quasi esclusivamente in alcuni 5 minuti intorno al momento in cui le partite terminano), vorrei sapere se ci sono delle modifiche che si possono apportare alla soglia in cui viene visualizzato il messaggio di carico elevato e gli utenti iniziano a essere “espulsi” dal topic… poiché ciò avviene sempre in un unico topic, il topic della partita.
Ciò e il messaggio di errore 502 (messaggio puramente nginx) che sperimentiamo ancora più raramente nello stesso contesto. Sospetto che probabilmente ci siano alcune configurazioni in nginx che potrebbero beneficiare di un affinamento, e so che non è il vostro compito, ma sono tutto orecchie per buoni suggerimenti 
.
Fornisci chiarimenti: stai riscontrando blocchi (gli argomenti non vengono aggiornati per i nuovi post) o stai ricevendo messaggi di errore relativi a carico eccessivo?
In questo thread sono presenti delle ottimizzazioni che apportano alcuni miglioramenti per i blocchi, ma aumentano anche il carico sul sistema, rendendo più probabili scenari di carico eccessivo.
In quelle situazioni che ho segnalato, a volte sperimentiamo il blocco degli argomenti, ma quando ciò accade il sistema mostra anche avvisi di carico estremo. Quindi non posso dirti cosa sia cosa.
Non ci dispiace il carico estremo, purché non espella gli utenti dagli argomenti o interrompa gli aggiornamenti per i nuovi post. In quel caso, preferiremmo anzi che il caricamento avvenisse lentamente (la rotellina potrebbe girare per 15 secondi per ogni utente che legge/posta, e preferiremmo questo al blocco o all’espulsione dell’utente).
Devo essere d’accordo. L’esperienza utente relativa al carico estremo è confusa per l’utente finale.
- Quanti utenti concorrenti hai?
- Che tipo di hardware?
- Link alle statistiche del tuo forum?
Ora che siamo sulla piattaforma SaaS CDCK, posso osservare la situazione solo dal punto di vista dell’UX.
Negli ultimi due settimane abbiamo avuto un bel po’ di attività nei giochi. I “blocchi” sono praticamente scomparsi con il cambio di piattaforma, ma c’è questa fluttuazione nel modo in cui il topic viene aggiornato, che potrebbe ancora confondere alcuni utenti. Tuttavia, il pubblico ha per lo più (90%) smesso di lamentarsi e si sta concentrando sui giochi, il che è un buon segno.
C’è però uno scenario che riesco a riprodurre con un’alta fiducia (di nuovo il 90%). La piattaforma ha problemi occasionali nel riprendere la sessione quando il topic del gioco è in una scheda in background (Android) o quando lo schermo è bloccato. Quando torno al topic attivo, di solito a causa di un evento interessante nel gioco, la visualizzazione del topic a volte non viene aggiornata. Posso vedere le avatar degli utenti lampeggiare in fondo al topic, ma non compaiono nuovi post. È necessario aggiornare il browser per recuperare completamente.
Il pattern di riproduzione non è il più semplice, poiché serve:
- Un topic attivo
- Un’azione significativa nel gioco → più attività nel topic
- Mantenere il topic in una scheda di browser in background o con lo schermo bloccato.
Anche noi ne soffriamo.
Un’altra cosa: quando si salta al primo messaggio non letto, questo comportamento può ripetersi alcune volte (si torna allo stesso “messaggio non letto” più volte, anche se la posizione del primo messaggio non letto dovrebbe essere cambiata ogni volta).
Per fare un esempio:
- Salto al primo messaggio non letto
- scorro e leggo i 100 messaggi non letti
- poi vado a un altro argomento o alla homepage…
- dopo un minuto circa, ci sono circa 30 nuovi messaggi non letti, ma quando faccio clic sull’icona, vengo rimandato nuovamente alla posizione del punto 1 (cioè 130 messaggi indietro e non solo i 30 nuovi non letti).
Tuttavia, ancora una volta, ciò avviene solo in argomenti molto molto attivi, per alcuni minuti durante il picco massimo di aggiornamenti e pubblicazioni da parte di tutti gli utenti nello stesso argomento contemporaneamente. È un po’ fastidioso, ma finora non è un problema insormontabile.
Lo considererei un successo.
Puoi fornire un caso riproducibile qui su meta? Probabilmente no, dato che richiede un gran numero di utenti attivi nello stesso argomento contemporaneamente?
Il mio pensiero attuale è che dovremmo creare una funzionalità di chat in tempo reale e istanzializzarla just-in-time, quando hai…
-
molti utenti
-
nello stesso argomento
-
contemporaneamente
-
allora, e solo allora, istanziare un overlay di chat in tempo reale e spingere fortemente gli utenti a utilizzarlo invece dei messaggi di risposta, forse persino disabilitare la possibilità di rispondere all’argomento con
Ehi, sembra che quello che volevi davvero fosse una chatroom.. eccola, divertiti! 
Sì, capisco cosa intendi, ma è così limitato a quelle occasioni che immagino non valga la pena. Di solito abbiamo partite come quella una o due volte a settimana e avviene principalmente nel periodo di 5 minuti subito dopo la fine della partita. Ma in realtà ci ho pensato diverse volte (sarebbe bello avere una funzione di chat temporanea o un meccanismo di commutazione per quel periodo di 90 minuti di una partita di calcio).
Comunque, proverò a riprodurla un giorno, registrando lo schermo per un po’.
La nostra istanza ha mostrato alcuni errori 429 con l’inizio delle partite dei playoff. @staff dovrebbe essere in grado di vederne alcuni negli ultimi 3,5 ore dei nostri log, e se ne prevedono di più quando verrà segnato il gol decisivo (la partita sta andando al secondo tempo supplementare mentre scrivo).
In ogni caso, se state ancora effettuando log e tracciamento, rimangono poche opportunità, dato che le finali e il successivo periodo di pausa si stanno avvicinando.
Volevo solo aggiungere il mio nome a questo thread per poterlo seguire. Siamo un nuovo forum di ginnastica. Ieri sera, durante le prove olimpiche statunitensi, abbiamo riscontrato quanto sopra insieme a un fenomeno di “congelamento”. Ecco il thread…
https://gymnaverse.com/t/us-wag-olympic-trials-night-2-live-discussion/1092
Ieri sera abbiamo avuto 4 unicorni.
Ho ridimensionato il server a 4 vCPU Intel e 8 GB di memoria su Digital Ocean e ho impostato…
unicorn_workers: 8
db_shared_buffers: “2GB”
Ci aspettiamo un traffico molto più elevato durante le Olimpiadi. Cosa altro possiamo fare per ottimizzare il server per un traffico “simile a una chat” durante la competizione?
Se hai centinaia di utenti in un singolo argomento che usano Discourse come chat e si tratta di un evento a tempo limitato, ti suggerirei di potenziare temporaneamente il server.
Il droplet Premium AMD più grande di Digital Ocean per i 16 giorni delle Olimpiadi è costato 54,85 $ e dovrebbe essere più che sufficiente per una community delle tue dimensioni.
Queste righe non sono presenti nel mio app.yml. Devo semplicemente aggiungerle?
Sì. Aggiungili nella sezione env.
Se questo è ancora nelle priorità dello staff, il nostro decollo è stasera alle 18:30 (UTC+3) e di nuovo domani alla stessa ora.
C’è grande attesa dopo due stagioni rovinate dal COVID, quindi mi aspetto picchi di traffico elevati su tappara.co
@ljpp
qual è la tua situazione attuale? Redis 6 ti ha aiutato?
Siamo ora su CDCK SaaS, motivo per cui abbiamo avvisato lo staff. Siamo una sorta di banco di prova per questa questione.