Concordo, qual è il valore di un contenuto che nessuno legge? E quali persone si metteranno davvero a leggere 10.000 post dall’inizio alla fine? 
È accettabile che alcuni argomenti siano chat effimere che scompaiono completamente nel tempo, come abbiamo definito in precedenza il traffico “corsia veloce” rispetto a quello “corsia lenta”.
Piccolo aggiornamento:
Dato che è stato segnalato e concordato di chiudere tutto ciò che supera il limite (e ristabilire i limiti), le prestazioni sembrano essere migliori, molto migliori. Riceviamo ancora alcuni messaggi del tipo “A causa di un carico estremo, questo viene temporaneamente visualizzato a tutti come lo vedrebbe un utente non autenticato”, ma in misura considerevolmente ridotta.
Detto questo:
Ancora una volta, un enorme grazie a tutti per l’aiuto e i feedback forniti.
Postgres 12 sarà d’aiuto in quanto riduce le dimensioni delle tabelle e degli indici del 20% nei test di @falco.
C’è già una data obiettivo per quello?
Ho iniziato a eseguire i benchmark oggi.
Devo lasciarli girare per un po’ qui su Meta per monitorare eventuali regressioni delle prestazioni prima di distribuirli ovunque.
Mi scuso per aver sollevato di nuovo questa questione, ma si tratta di un problema diverso dalla migrazione a PostgreSQL (che non riesco ancora a eseguire a causa delle dimensioni).
Dall’ultimo rebuild, la dimensione del database non smette di aumentare:
L’ultimo rebuild è stato il 17 maggio e da allora la dimensione del DB non ha smesso di crescere, raggiungendo 57,3 GB. La parte più grande è nella tabella post_timings.
Il mio problema principale è che sto cercando di eseguire l’aggiornamento a PostgreSQL (che ridurrà le dimensioni degli indici del 20%, ma non risolverà il problema a lungo termine). Dai commenti qui dello Staff, emerge che questa dimensione non è la norma, quindi continuerà ad aumentare, diventando costosamente ingestibile. Più passa il tempo, più aumenta, creando un circolo vizioso che diventa un incubo da mantenere. Quindi il mio problema principale rimane: esiste un modo per risolvere questo problema relativo a post_timings? C’è qualcosa da eliminare?
Posso comprimere le tabelle o fare qualcosa di simile?
Grazie a tutti per l’aiuto.
Al momento non c’è modo di evitarlo. Se il tuo forum è davvero grande, avrà una tabella dei tempi di esecuzione molto estesa.
Meta è un’istanza molto vecchia, ma è di dimensioni medie e ha una tabella post_timings di soli 4 GB. D’altra parte, ospitiamo un’istanza con meno di due anni di vita e la tabella post_timings dovrebbe superare i 100 GB già ora.
Ospitare forum di grandi dimensioni costerà di più e al momento non ci sono vie d’uscita.
Forse potresti spostare il tuo database su un droplet autonomo da 20 (80 GB di disco) e mettere il sito web su un altro droplet da 10 ? 30 $ al mese per quello che sembra essere una comunità piuttosto grande sembrano ragionevoli.
Grazie mille per il tuo aiuto, @Falco.
Beh, sì, come ho detto, chiedevo solo perché non esiste magia quando si tratta di spazio. Sto valutando la divisione, ma l’app diventerà troppo lenta a causa delle prestazioni (è una lunga storia, sto prendendo nota dei test e li presenterò qui più tardi in modo che tutti possano utilizzarli se li ritengono utili).
Ho eseguito il test di cui ti ho chiesto riguardo al ripristino di un backup e penso che questa possa essere un’ottima opportunità da sfruttare, poiché ciò che vedo immediatamente è un risparmio del 30% sull’uso del disco (sto ancora eseguendo alcuni test per verificare che non manchi nulla), ma ora c’è un piccolo problema con questo approccio. Quindi, anche se i benefici immediati sono notevoli, questo genererà alcuni problemi (ancora di più perché non so se le immagini memorizzate siano nella cache o non funzionino affatto, e sì, il backup le include).
Sto prendendo appunti in modo da poter aggiornare l’OP; la mia idea è aggiungere una breve serie di note per le persone che potrebbero preoccuparsi delle prestazioni e di tutte le modifiche che ho apportato finora.
Applicare un timer di “cancellazione automatica delle risposte” è una buona soluzione da un punto di vista tecnico?
In realtà è un’idea piuttosto valida e risolve il problema dell’usabilità (perché, come abbiamo detto, nessuno leggerà 10.000 messaggi). Quindi la grande domanda è se questo potrebbe essere gravoso per il server e il database.
Non sono sicuro che un argomento con 9000 risposte, di cui circa 8600 cancellate, sia ottimale per le prestazioni, ma ne dubito. Cosa ne pensi @eviltrout?
Pensavo che i post “nascosti” venissero completamente rimossi dal database dopo un certo periodo, ma ora vedo che probabilmente non è così.
Quindi, dal punto di vista delle prestazioni, la mia idea non può risolvere il problema.
C’è un modo per “eliminare definitivamente” questi dati?
I post eliminati vengono rimossi in modo soft. Tuttavia, sono spesso indicizzati, quindi potresti notare alcuni miglioramenti quando ne vengono rimossi molti. Non lo consiglierei comunque. Se esiste un modo per spostare la discussione in un nuovo argomento una volta che uno diventa troppo grande, potrebbe esserti molto utile.
Cosa intendi con questo? Avere il database e l’app web su server separati dovrebbe migliorare le prestazioni, perché, sebbene ci sarà un po’ di latenza tra i server, il tuo Unicorn e Postmaster non dovranno competere per CPU e RAM.
Assicurati che i server si trovino nella stessa regione di DO 
Scusa, hai ragione: questo li libererebbe entrambi e otterrebbe prestazioni migliori rispetto a tutto su un’unica istanza (stavo confrontando con le risorse che sto utilizzando su una singola macchina e con le ottimizzazioni che ho fatto finora).
È effettivamente un’ottima idea; lascia che provi a risolvere il problema “impossibile di ricostruire il contenitore dei dati” che ho, e questo sarà il mio prossimo passo in questo viaggio.
Ho cercato a lungo su questo argomento, ma non sono riuscito a trovare documentazione su come farlo in modo ottimale. Esiste una guida del genere?
Stiamo anche iniziando a raggiungere un limite con la nostra installazione standard su VPS singola. Il nostro dilemma piuttosto unico riguarda le chat di gioco, che si svolgono durante le partite di hockey e causano picchi netti di attività/carico. Soprattutto se accade qualcosa di straordinario durante la partita.
Immagino che dovresti avere qualcosa di abbastanza potente da resistere ai tuoi momenti di maggiore affluenza. Oppure dovresti aumentare le prestazioni durante questi periodi. Forse cerca un VPS che puoi pagare a ore. Una soluzione (continuando il consiglio precedente) sarebbe quella di spostare il contenitore web su un VPS estremamente potente, che paghi solo per poche ore quando ci sono i giochi.
Devi:
Eseguire PostgreSQL altrove (su un droplet o utilizzando un servizio gestito come Worry-Free Managed Database Hosting | DigitalOcean) e spostare i tuoi dati lì.
Seguire la guida Eseguire Discourse con un server PostgreSQL separato
E questo può essere ottenuto anche utilizzando i prodotti containerizzati di Discourse? Web_only e data, giusto?
Dalla mia esperienza, questo problema non è risolto direttamente da alcun approccio attuale né ha una soluzione lineare. In realtà, separarli su macchine diverse non è una soluzione immediata per tale questione.
Anche noi sperimentiamo forti cali e messaggi come “il sito è estremamente occupato, quindi ti stai mostrando come se non fossi connesso” quando si verifica un evento importante (come un gioco, come ha detto @ljpp), e ciò trascina giù l’intero sito, non solo le persone all’interno di quel topic.
Quindi, ho provato due cose diverse: una configurazione separata e una “macchina grande”. Entrambe presentano questo tipo di problemi. Le mie istanze sono monitorate con Prometheus e i log sono visibili su Grafana, ecc., quindi ho un controllo molto granulare sulle prestazioni hardware/container e posso confermare che, in realtà, non importa cosa si faccia, il problema si verifica comunque.
Se metti una macchina grande dietro di essa, potresti ritardarlo leggermente, ma otterrai comunque errori e cadute di sessione, e la macchina rimarrà con un utilizzo quasi nullo, sia per disco, CPU o RAM. Questo accade sia con l’“installazione predefinita” che con le installazioni a “due container”.
Con macchine diverse, il problema è lo stesso, indipendentemente dal fatto che le macchine siano dello stesso tipo o che una sia “CPU-Optimized” e l’altra “Disk-Optimized”, ecc. A questo devi aggiungere anche il livello aggiuntivo di possibile guasto della connessione tra due macchine diverse, che inevitabilmente introdurrà latenza, sebbene questa quantità di latenza possa variare in base a come configuri tale connessione e a “quanto distanti” siano le due macchine l’una dall’altra. Tuttavia, otterrai lo stesso comportamento.
Come nota, questo tipo di comportamento si verifica anche con cose come il plugin Babel; tuttavia, mi sembra che il plugin Babel possa gestire molte più scritture “simultanee”, anche se le “chat” sono in realtà topic nascosti. La differenza sta nel modo in cui vengono presentate e “aggiornate”/“recuperate”. Questa differenza di comportamento mi ha portato alla conclusione che si tratti di una correlazione applicativa che deriva da un problema di tipo FrontEnd che “fa crashare” l’app (essendo il FrontEnd non il mio ambito di competenza, a differenza del BackEnd) e dalle operazioni in corso tramite la pubblicazione e le persone che rimangono su un topic in attesa che si “aggiorni da solo” con decine di messaggi in un singolo minuto.
A questo devi aggiungere anche il fattore umano: quando le persone percepiscono che il sito è “lento” o che un topic “non si aggiorna velocemente come dovrebbe”, premeranno F5 all’infinito, aggiungendo ulteriore carico. Ma buona fortuna nel “educare” su questo aspetto
