Il nostro sito Discourse conta oltre 10.000 utenti e circa 700 utenti attivi giornalieri, con una media di 10.000 post inviati al giorno. La nostra community registra oltre 160.000 visualizzazioni di pagina al giorno, inclusi crawler e utenti anonimi. Quasi tutti i nostri utenti si connettono tramite dispositivi mobili.
Abbiamo eseguito la community in modalità standalone su un singolo VPS con 16 core CPU e 24 GB di RAM, configurando app.yml con questi valori:
Con la configurazione sopra indicata, alcuni utenti segnalano che il sito si carica lentamente per loro e, in alcune occasioni, durante l’invio di un post, lo schermo diventa bianco (l’intestazione rimane comunque visibile). Inoltre, durante le ore di punta, le prestazioni del sito rallentano talvolta.
Potete spiegare se abbiamo configurato male qualcosa o se sono necessarie più risorse?
10.000 post al giorno sono piuttosto tanti, considerando il numero di visualizzazioni di pagina. Posso immaginare che, data la tua configurazione, tu stia raggiungendo alcuni limiti di risorse e sospetto che il problema sia il database. Potresti provare a passare a un’architettura multi-container, scaricando di fatto i worker Unicorn dal server principale.
Secondo la tua risposta, aumentare le risorse in questa configurazione non aiuta a risolvere il nostro problema? Ad esempio, 24 core CPU con 32 GB di RAM.
Potrebbe benissimo essere, ma prima proverei a scalare in orizzontale tutto ciò che può essere scalato in orizzontale. Questo ti darà anche un’idea molto più chiara di dove si trova il collo di bottiglia.
La maggior parte dei problemi di prestazioni può essere risolta semplicemente aggiungendo più risorse al problema. La parte difficile è farlo in modo intelligente, in modo da risparmiare qualche euro (o potenzialmente molto denaro).
Grazie per la tua competenza e i tuoi consigli amichevoli; leggerò sicuramente come implementare questa soluzione. Un’altra domanda che ho è: quali impostazioni dovrebbero essere applicate nell’app per le specifiche che ho menzionato sopra (24 core CPU con 32 GB di RAM)?
Le impostazioni attuali sono appropriate o è meglio aumentare i valori?
Difficile dirlo senza ispezionare il sistema e vedere cosa sta succedendo.
Dato che hai detto che la maggior parte dei problemi si verificano durante l’invio di un post, il problema è probabilmente legato alla scrittura sul database e non credo che aumentare ulteriormente shared buffers sarà di grande aiuto, ma puoi provare. Ho visto che viene portato a oltre il 50% della memoria (contro ogni consiglio), quindi potresti provare ad aumentarlo gradualmente fino a 12 GB.
Se non stai riscontrando errori 502, non ha senso aumentare nemmeno UNICORN_WORKERS.
Non hai menzionato il suo utilizzo, quindi penso che la prima cosa da fare sia aggiungere una CDN; questo ridurrebbe notevolmente il carico sul VPS, poiché le richieste più pesanti non raggiungerebbero il server.
Oltre alla CDN, ti consiglierei anche di optare per un archivio simile a S3, che ti permetterebbe di scalare separatamente lo storage e le risorse del VPS (se la tua community è ricca di upload).
Queste raccomandazioni aiutano molto a ridurre il carico, e l’aumento di prezzo è molto inferiore rispetto all’acquisto di un VPS più grande.
Grazie @marianord, purtroppo non utilizziamo un CDN. La velocità di caricamento nel nostro forum non è molto elevata. La maggior parte delle volte, gli utenti discutono di vari argomenti. Ad esempio, nell’ultimo anno abbiamo avuto circa 2,8 milioni di post e 2,7 milioni di like, ma solo 25 GB di file caricati.
Pensi che, in base alle informazioni che ho fornito, l’utilizzo di un CDN come S3 possa ridurre il carico sul nostro server?
Non sono d’accordo con @marianord. Non penso che un CDN farebbe una differenza significativa rispetto al carico sul tuo server.
Si tratta solo di file statici e non sono affatto pesanti da servire.
S3 scarica i file e i backup su un altro server gestito da un provider cloud (una sintesi molto generale)
La CDN memorizza nella cache i file statici del tuo server (immagini, JS, CSS) per servire da più server (PoP) in tutto il mondo, accelerando il caricamento di queste risorse.
Almeno questa è la mia esperienza: riduci il numero di richieste che arrivano al tuo server, diminuendo così il carico. È molto più semplice servire solo 10 richieste JSON per utente rispetto a 100 richieste per utente.
Forse questo non risolverà tutti i problemi che sta affrontando @nildarar, ma ridurrà il carico pesante sul server eliminando tutte le richieste statiche (quelle in cache) dal server Discourse.
Una richiesta per un file statico non ha un impatto significativo sul carico complessivo del server. Le richieste per contenuti dinamici sono quelle più pesanti.
In generale, una richiesta json non è una risorsa statica che verrà memorizzata nella cache di una CDN. Si tratta di contenuti dinamici generati al volo. Perché stai parlando di file JSON in un contesto CDN?
richieste statiche ≠ carico più pesante.
Mi dispiace, ma questo è davvero un consiglio pessimo.
Questo è un esempio proveniente da una macchina con 6 CPU (quindi la CPU totale arriva al 600%) che esegue Discourse senza CDN o S3.
Vero, ma Discourse ha alcune eccezioni, come i fogli di stile serviti da Ruby, quindi avere una CDN con caching significa che quelle richieste non consumano i processi Unicorn.
Per quanto riguarda il problema dell’OP, la prima cosa necessaria è che una persona esperta esegua un’analisi delle prestazioni durante le ore di punta e identifichi qual è l’attuale collo di bottiglia.
Grazie per la tua guida. Fino a qualche mese fa utilizzavamo il servizio CDN di Cloudflare e abbiamo apportato modifiche efficaci ai contenuti statici tramite le regole delle pagine. In seguito, ho letto da qualche parte che l’uso di proxy come Cloudflare riduce drasticamente le prestazioni di Discourse, quindi lo abbiamo disabilitato.
Ieri abbiamo aumentato i core della CPU da 16 a 24 e apportato le seguenti modifiche al file app.yml:
Con queste modifiche, il nostro problema è stato risolto temporaneamente, ma credo che dovremo apportare un cambiamento fondamentale nei prossimi mesi.
Quindi, secondo le tue raccomandazioni, l’uso di una CDN per servire i contenuti statici e la divisione di Discourse in due container separati hanno la priorità più alta per il miglioramento delle prestazioni.
Queste informazioni potrebbero essere datate, ma ricordo di aver letto che Discourse preferisce un numero inferiore di CPU più potenti rispetto a un numero maggiore di CPU meno potenti… anche se si aggiorna il numero di worker unicorni.
@codinghorror, puoi confermare se queste informazioni sono ancora corrette?
Utilizzare qualcosa come Prometheus + Grafana può aiutarti a ottenere solo lo storico dei dati, invece di vederli in tempo reale e poi effettuare un’analisi più approfondita di ciò che sta accadendo.
Ciao di nuovo
Seguendo i vostri consigli, abbiamo installato Prometheus e monitorato le prestazioni della community per un po’. Vi preghiamo di consultare i rapporti qui sotto e confrontarli con i valori che rilevate nelle diverse installazioni.
