Abbiamo 5 milioni di post e la ricerca è molto veloce. L’hosting avviene su 6 core condivisi di un Xeon E5-2680 da 2,8 GHz con 16 GB di RAM e storage SSD. Detto questo, non ho metriche su quanti post simultanei gli utenti avviano; potrebbero esserci problemi di locking.
La pubblicazione, invece, è spesso piuttosto lenta. Potrebbero volerci 6-7 secondi affinché un post venga inviato. Discourse non è bloccante quando elabora, quindi ciò non compromette l’esperienza dell’utente.
Credo che questo sia molto probabilmente il caso per qualsiasi argomento con centinaia o migliaia di post. Per argomenti brevi non dovrebbe essere così.
Ricordo che il forum di @Wingtip ha un sacco di argomenti molto lunghi.
I tempi di pubblicazione di 6-7 secondi sono specifici per gli argomenti mega? Se rispondi a un argomento con 100 risposte, impiega anch’esso 6-7 secondi?
Non sono riuscito a riprodurre il problema in questo momento: la lentezza nella pubblicazione è intermittente. Non sembra correlata al numero di post nel thread. Forse è un problema di blocco dovuto a qualcun altro che pubblica contemporaneamente o qualcosa di simile.
7 post = molto veloce, più o meno come qui su meta
500 post = forse leggermente più lento, non troppo male. Forse 1,5 secondi?
16k post = sembra più o meno lo stesso che con 500
E credo che le prestazioni risentano anche del fatto che un gruppo di persone stia accedendo a un argomento enorme, il che rallenta l’intero server PG a causa delle richieste in coda.
Come ti senti coraggioso? Ti dispiace abilitare mini_profiler per un po’? Ti fornirà i tempi di esecuzione a lato, così potremo isolare quale query sta creando problemi!
Quanto incide l’attivazione sulle prestazioni complessive? E può essere abilitata senza una ricostruzione del sito? Non sono riuscito a completare una ricostruzione con successo dal cambiamento a PostgreSQL 12, nemmeno impostando l’opzione per rimanere su PG10.
Devi impostare il tuo indirizzo email come email dello sviluppatore nel file app.yml. Puoi applicarlo senza ricompilare distruggendo e riavviando il container. Se hai apportato modifiche al container, aggiornando con discourse docker, queste andranno perse.
Puoi anche modificare config/discourse.conf all’interno del container e poi
Dato che le ricostruzioni stanno fallendo, la mia preoccupazione è che, se distruggo il container, rimarrò completamente senza vie d’uscita. Ho avuto così tanti errori nel tentativo di aggiornare a PostgreSQL 12 ieri che non mi sento affatto tranquillo nel apportare modifiche finché non sarò certo di non far andare il sito offline per un periodo prolungato.
Beh, il consiglio gratuito vale quanto si paga, ma è abbastanza sicuro eseguire:
cd /var/discourse
./launcher enter app
vi config/discourse.conf
# in vi, modifica la riga developer_emails inserendo il tuo indirizzo email e esci da vi
sv unicorn restart
# vai nel panico per i 30-90 secondi necessari al server web per riavviarsi e iniziare a servire le pagine
Tuttavia, puoi comunque rompere qualcosa in questo modo. Credo sia possibile danneggiare quel file di configurazione in modo che Discourse non si avvii.
È questo che ti serviva? Questo post è stato inviato in un thread con 16k messaggi. Il tempo di pubblicazione è sembrato normale, non particolarmente lento.
Ottimo! Qualsiasi miglioramento significativo nei tempi di pubblicazione renderà davvero felici i nostri utenti; al momento è l’aspetto che genera più lamentele. Anche se non ho dubbi che, poco dopo, troveranno qualcos’altro di cui lamentarsi.
Se ti fa sentire meglio, mi sono lamentato anche io di quella query, perché ho così tanto stato di lettura qui su meta. Stiamo facendo un lavoro inutile per contare le cose ad ogni risposta…
Nel nostro test di importazione da un altro software, abbiamo un argomento con poco più di 200.000 post e sono riuscito a pubblicarci senza problemi. Deve essere perché non è la dimensione dell’argomento a contare, ma piuttosto l’utente che effettua la pubblicazione.