Errore di carico estremo

“A causa di un carico estremo, questo viene temporaneamente visualizzato a tutti come se l’utente non fosse connesso”

Gestisco un sito web che offre thread in diretta durante le partite di basket e ho avuto problemi con il server che si sovraccaricava, mostrando questo messaggio durante le partite (picchi di attività).

C’è un modo per identificare la soluzione migliore per risolvere il problema? Si tratta della velocità di archiviazione, della memoria o della CPU? C’è qualcosa che posso fare oltre a potenziare il server o, se decido di farlo durante questi periodi, cosa dovrei potenziare?

2 Mi Piace

Far sì che meno persone usino il forum? Sarebbe ancora meglio se distribuissero l’uso nel tempo invece di farlo tutti durante la partita.

Ma nessuna di queste soluzioni è davvero utile. Dato che sai quando si svolgono le partite, potresti potenziare il server solo durante la partita o gestire più server durante la partita dietro un bilanciatore di carico.

Hai bisogno di più core CPU e più veloci, e di più RAM, per poter aumentare il numero di processi web (Unicorn Workers) e gestire il traffico di picco.

4 Mi Piace

È un’area su cui @sam sta lavorando attivamente. Sembra che le versioni più recenti di Discourse abbiano peggiorato le prestazioni in questo settore.

Detto questo, la vera soluzione è utilizzare uno strumento di chat dal vivo se hai bisogno di interazioni in tempo reale per centinaia di persone contemporaneamente – anche se continuo a chiedermi come e perché la chat sia “utile” quando scorre così velocemente che nessuno riesce davvero a vederne nulla, come nelle streaming di Twitch e YouTube. :man_shrugging:

2 Mi Piace

Questo thread descrive molto bene il problema.

Questa è stata la mia esperienza con un forum di calcio durante una partita, prima che si manifestassero i problemi:

Digital Ocean
1 CPU 1 GB = 30-40 utenti in una situazione simile a una chat
2 CPU e 2 GB = 70-80 utenti in una situazione simile a una chat
4 CPU e 8 GB = adatto per 120 utenti e 1000 post in 2 ore. Non ho raggiunto il limite.

Con Hetzner (sito di mirror)

La mia esperienza è stata:
3 CPU (chip AMD CPX 21) e 4 GB = difficoltà con 20 utenti
2 CPU (Intel) e 8 GB = nessun problema con 20 utenti.

Non sono mai riuscito a testare con più utenti.

La cosa fondamentale è migliorare CPU e RAM. E ANCHE modificare il file app.yml.

Aggiungi più unicorn qui e modifica anche db_shared_buffers.

5 Mi Piace

Per i forum sportivi, si avvicina di più agli aggiornamenti testuali in diretta delle partite. Le persone non stanno tanto chattando (anche se ciò accade in una certa misura, specialmente durante l’intervallo), quanto piuttosto ricevendo un commento testuale in tempo reale da parte di altri tifosi.

Molti si collegano al forum semplicemente per leggere il commento testuale in diretta: le opinioni e i pensieri dei tifosi chiave sugli eventi principali della partita, dalle reazioni divertenti alle analisi serie.

Se hai perso la partita, le persone si collegano per leggere il commento evento per evento. È perfetto per chi è al lavoro :wink: È più personale e parziale rispetto ai commenti testuali dei giornali o delle emittenti TV.

6 Mi Piace

È corretto. discourse-setup lo farà se lo esegui sul server aggiornato.

2 Mi Piace

Ti capisco, è qualcosa che @sam, @eviltrout e io stiamo esaminando attentamente… la situazione di ‘centinaia di utenti connessi e che navigano lo stesso argomento contemporaneamente’ si sta presentando con una certa frequenza ultimamente, man mano che Discourse diventa più popolare.

Potrebbe essere necessario introdurre un nuovo comportamento in questi casi; dei cartelli con la scritta ‘corsia preferenziale’ dovrebbero probabilmente iniziare a comparire nell’interfaccia degli argomenti in qualche forma… :warning:

4 Mi Piace

Una cosa importante da tenere a mente qui è che le implementazioni di “chat” in genere trasmettono il contenuto effettivo agli abbonati.

In Discourse abbiamo un processo piuttosto complesso che rende l’implementazione ingenua complessa, portando a grandi quantità di traffico.

  1. Un utente pubblica una risposta
  2. Tutti gli utenti che stanno visualizzando l’argomento scoprono tramite broadcast che c’è nuovo contenuto
  3. Tutti gli utenti richiedono al server il contenuto del post (100 visualizzatori = 100 richieste)
  4. Recuperiamo le immagini e le ottimizziamo
  5. Tutti gli utenti che stanno visualizzando l’argomento scoprono tramite broadcast che c’è nuovo contenuto
  6. Tutti gli utenti richiedono al server il contenuto del post (100 visualizzatori = 100 richieste)

(abbiamo varie ottimizzazioni, limiti di frequenza, nuovi tentativi e così via, ma questo è il succo)

Tutte queste richieste devono passare attraverso il nostro processo di sicurezza per garantire che l’utente abbia i diritti per visualizzare il post e così via.

Se il contenuto fosse piuttosto breve e potessimo in qualche modo capire come gestire la sicurezza in modo più leggero per la “corsia veloce”, potremmo distribuire i messaggi della chat tramite broadcast. Questo porterebbe a prestazioni significativamente migliori; probabilmente potremmo gestire 10.000 utenti su un singolo droplet Digital Ocean da 2 GB con quel design.

La sicurezza è molto complessa. Anche la memorizzazione nella cache è complessa a causa dei problemi di invalidazione della cache.

Quindi, sì, stiamo assolutamente pensando a questo problema. Ma allo stato attuale…

Molti utenti connessi che visualizzano un argomento + molto nuovo contenuto su un argomento = bollette del server costose.

7 Mi Piace

È fantastico!

A dire il vero, so giusto abbastanza da essere pericoloso. Sono il tipo che impara giocando (e rompendo). Apprezzo davvero lo sforzo incredibile fatto per creare questa piattaforma. Quando ho creato il mio primo forum 12 mesi fa, ne ho realizzati 12 versioni diverse :laughing: Vanilla, MyBB, SMF, Flarum, ecc. Discourse è stato di gran lunga il migliore.

Uno dei punti di forza maggiori è lo sviluppo attivo. È bello vedere come voi ascoltiate la comunità e continuiate a migliorare.

6 Mi Piace

Hai impostazioni consigliate per questo?

1 Mi Piace

Ciao ragazzi, il mio sito sembra essere peggiorato, con lo stesso pacchetto DO (8 GB, 4 CPU), il mio sito sta iniziando ad avere difficoltà con 60-70 utenti che pubblicano 1000 post.

Mi chiedevo solo due cose.

  • È possibile rimuovere il messaggio di carico estremo? Sembra allarmare gli utenti più che essere utile.

  • Ci sono progressi nel gestire un gran numero di utenti?

Nel frattempo esplorerò la modifica degli unicorni e la disabilitazione dei plugin, ecc. per aiutare a liberare risorse.

Se hai ridimensionato dopo l’installazione, hai eseguito nuovamente discourse-setup o hai modificato le impostazioni manualmente?

L’ho appena fatto manualmente, avrei dovuto eseguire discourse setup?

Se hai apportato le modifiche, devi ricompilare (non sono sicuro se un destroy/start sia sufficiente).

1 Mi Piace

Quindi, solo per assicurarmi di non fraintendere, dopo aver modificato yml ho semplicemente eseguito ./launcher rebuild app

Vale la pena provare ./discourse-setup invece?

(Come menzionato in precedenza, ho solo abbastanza conoscenza da essere pericoloso :sweat_smile:)

Dovrebbe andare bene. Discourse-setup cambierà le impostazioni di memoria per te. Se l’hai fatto, allora dovresti stare bene.

1 Mi Piace

Giusto per essere sicuri e per curiosità: avete configurato lo swap?

Ho un file di swap da 2 GB, consigliereste un file di swap da 8 GB? (corrisponde alla quantità di RAM?)

Se hai spazio su disco, più swap non farà male. free ti dirà come viene utilizzata la memoria e quanta swap viene utilizzata.

1 Mi Piace