Ho una nuova installazione di Ubuntu 20, Docker e Discourse. Non ho aggiunto alcun plugin e ho solo due utenti nel mio database, tuttavia le build richiedono più di 40 minuti per essere completate! Non c’è una parte specifica del processo di build che sia lenta, l’intera cosa richiede un’eternità per essere completata. È un server con buone specifiche e ne ho un altro che serve felicemente 20 siti web dei miei clienti, quindi non è un problema di prestazioni.
Si blocca qui per almeno 4 minuti:
warning Resolution field "lodash@4.17.21" is incompatible with requested version "lodash@4.17.15"
Si blocca di nuovo qui immediatamente dopo per altri 4-5 minuti:
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".
Ho provato a fare la build con --skip-prereqs senza successo, ci vogliono ancora 40+ minuti per ogni rebuild.
C’è qualcosa in particolare che pensi possa causare il problema?
Abbiamo una regressione nei tempi di compilazione causata dalla nuova funzionalità per eseguire i test dei temi tramite l’interfaccia utente. Stiamo monitorando attentamente questa situazione e cercando di risolverla.
Grazie per la conferma @Falco, 1 GB di RAM qui (poco ma mai più necessario per un sito leggero). Ci vogliono più di 30 minuti per la build (normalmente ci vogliono circa 10 minuti).
Rafael, questa è una regressione sulla versione beta 2.9.0 o sulla versione stabile 2.8.0?
Tornando al primo post, qualcuno sa da dove proviene quell’avviso?
Non so se sia davvero qualcosa da considerare, ma personalmente, in molte cose ho notato che le prestazioni diminuiscono quando si utilizza Ubuntu 20.04 (Discourse, WebServer, Game Server) anche provando diversi modi per cercare di ottimizzare
Al momento sto eseguendo Discourse in un Droplet per test con le stesse caratteristiche, ci vogliono circa 8-12 minuti per ricostruire (Ubuntu 18)
Non credo che la build si stia “bloccando” a questi avvisi. Sta semplicemente compilando silenziosamente e gli avvisi vengono visualizzati come parte del processo.
Cioè, gli avvisi o il loro problema sottostante non contribuiscono al lungo tempo di compilazione.
Questo è un cambiamento gigantesco su cui stiamo lavorando da anni e che sta arrivando alle fasi finali. Durante questo periodo, ci sarà un periodo in cui “le cose peggioreranno prima di migliorare”, e questo è uno degli effetti collaterali “peggiori”.
C’è anche la possibilità di consentire alle persone con CPU lente di disattivare le source map e altre funzionalità “nice to have” per velocizzare le loro ricostruzioni.
Apprezzo l’aggiornamento @Falco Su una CPU quad con 8 GB di RAM su Linode e normalmente questa è una configurazione fantastica, ma ora è un incubo. Abbiamo una serie di modifiche che avevamo in programma di apportare, ma dovremo aspettare ora finché il deployment non tornerà a velocità normali o quasi.
@Falco Sto anche notando che per le ultime release le prestazioni del server stanno peggiorando, ci vuole più tempo per caricare i siti e consuma più memoria. Non ci sono state modifiche alla mia configurazione negli ultimi 2 anni (plugin, hardware, ecc.) e anche il numero di utenti attivi sul sito è lo stesso. Esiste un modo per monitorare oggettivamente le prestazioni del sito da Discourse che possiamo quindi riportare qui. Al momento, l’unico modo che conosco è quando apro il sito, ci vogliono più di 8 secondi per caricarlo la prima volta (con le build precedenti, sarebbe sempre stato inferiore a 2-3 secondi).
Che tempi di ricostruzione state vedendo? Ho dovuto ricostruire a causa di una modifica SMTP e ci sono voluti poco meno di 12 minuti per un sito PICCOLO (30 utenti, 400 post).
Questo argomento riguarda i “tempi di compilazione” e non i tempi di caricamento delle pagine. Se stai parlando del degrado dei tempi di risposta delle pagine, apri un nuovo argomento al riguardo con alcuni dati.
Penso di aver capito perché le pagine impiegano così tanto tempo a caricarsi. La dimensione del database condiviso in app.yml era impostata uguale alla memoria totale del sistema. Reimpostala al valore predefinito (25%), ricostruisci e ora è inferiore a un secondo.
Grazie per l’aggiornamento 
Su una CPU quad con 8 GB di RAM su Linode e normalmente questa è una configurazione fantastica, ma ora è un incubo. Abbiamo una serie di modifiche che avevamo in programma di apportare, ma dovremo aspettare ora finché il deployment non tornerà a velocità normali o quasi.