Abbiamo appena registrato un picco di traffico di circa 1.500 utenti concorrenti (per lo più anonimi) che visitavano una singola pagina.
Il forum è passato alla modalità in cui viene visualizzato un avviso a tutti i membri riguardo all’elevato carico.
Droplet Digital Ocean ottimizzato per la CPU
CPU dedicata: 4 vCPU
RAM: 8 GB
Worker Unicorn: 10
Considerato che vengono utilizzati solo circa il 50% della RAM e della CPU, aumenterebbe l’efficacia dei worker Unicorn per gestire casi di picco di traffico provenienti da visitatori anonimi o no?
Ho aumentato i worker a 24. Nessuna differenza (rimane comunque “A causa di un carico estremo, questo viene temporaneamente mostrato a tutti come se fosse visualizzato da un utente non autenticato.”), con un picco simile di visitatori concorrenti (99% anonimi) proprio ora:
@sam Hai qualche idea su come ottimizzare ulteriormente il traffico di picco proveniente da utenti anonimi (ad esempio, se un singolo argomento diventa virale sui social media). In entrambi i casi sopra descritti, memoria e CPU hanno ancora ampio margine (secondo Digital Ocean) e non abbiamo nemmeno raggiunto un carico di 4; tuttavia, il forum entra in modalità “carico estremo”, nonostante il numero di worker sia stato triplicato.
Credo che il monitor dei dati di DO non sia sufficientemente sensibile e sia in qualche modo fuorviante. Ho fatto esperimenti con carichi estremi su Hetzner e Digital Ocean. Con Hetzner, quando è apparso il messaggio di carico estremo, c’è stato un picco breve e acuto che ha raggiunto il 120%.
È durato forse un secondo, prima di scendere al livello del 40-50%.
Ho replicato la stessa situazione con Digital Ocean e, per quanto ricordo, il utilizzo della CPU non è mai superato il 50% (anche se non era possibile modificare l’asse X al livello dei secondi).
Il mio parere è che il livello della CPU di DO sia forse una media calcolata su 5 o 15 secondi. Quindi non si vedono i picchi brevi e acuti.
Avremo bisogno dei report dell’exporter Prometheus per approfondire l’analisi.
Se disponi di RAM e CPU sufficienti, puoi sempre aggiungere altri worker Unicorn: questo permetterà di gestire i picchi di carico. Tuttavia, è importante evitare lo swap della memoria, poiché le prestazioni ne risentirebbero drasticamente.
Sembra che in un caso del genere, la pagina di quel singolo argomento dovrebbe poter essere memorizzata nella cache e servita staticamente per un breve periodo senza dover affatto colpire il backend. Non ho idea se Discourse possa farlo (cioè impostare le intestazioni di controllo della cache quando è sotto carico e sta servendo contenuti agli utenti anonimi) e se l’installazione DO abbia un proxy di caching capace nella catena, ma è un’idea di sviluppo che potrebbe valere la pena considerare se non ho completamente torto e non è già stata realizzata.
Forse @sam ci ha già pensato o l’ha già fatto, oppure sa perché sarebbe una cattiva idea!
Sì, ma il mio suggerimento è di reindirizzare solo gli utenti anonimi a una pagina in cache con un timeout breve (60s?) per alleggerire il carico, nella speranza che il resto del sito possa continuare a funzionare in modalità lettura-scrittura.
Sarebbe fantastico. Attualmente, se mettiamo in evidenza un argomento sul nostro canale Telegram con oltre 200.000 iscritti, l’intero sito Discourse passa in modalità “sola lettura” per quasi un’ora. Anche se gli utenti connessi sono circa 50 (il 99% è traffico anonimo).
Questo accade già: abbiamo una cache molto aggressiva direttamente in Redis per gli utenti anonimi sulle pagine dell’elenco dei topic e sulle pagine dei topic, con un timeout di 60 secondi.
Proverò a far funzionare Prometheus per individuare il collo di bottiglia, ma probabilmente è il monitoraggio di DO a essere in ritardo, come menzionato da @Alec. Se questo è il caso, immagino che la strada da seguire sia una macchina più potente?
