Ich habe eine frische Installation von Ubuntu 20, Docker und Discourse. Ich habe keine Plugins hinzugefügt und nur zwei Benutzer in meiner Datenbank, aber die Builds dauern über 40 Minuten! Es gibt keinen bestimmten Teil des Build-Prozesses, der langsam ist, der gesamte Vorgang dauert ewig. Es ist ein ziemlich guter Server, und ich habe einen anderen, der 20 Websites meiner Kunden problemlos bedient, also ist es kein Leistungsproblem.
Hängt hier mindestens 4 Minuten:
warning Resolution field "lodash@4.17.21" is incompatible with requested version "lodash@4.17.15"
Hängt hier sofort danach noch einmal für weitere 4-5 Minuten:
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".
Ich habe versucht, mit --skip-prereqs zu bauen, aber ohne Erfolg, es dauert immer noch 40+ Minuten für jeden Rebuild.
Gibt es etwas Bestimmtes, das Ihrer Meinung nach das Problem verursachen könnte?
Wir haben eine Regression bei den Build-Zeiten, die durch die neue Funktion zum Ausführen von Theme-Tests über die Benutzeroberfläche verursacht wird. Dies ist etwas, das wir genau beobachten und zu beheben versuchen.
Danke für die Bestätigung @Falco, 1 GB RAM hier (knapp, aber nie mehr für eine schlanke Website benötigt). Es dauert über 30 Minuten zum Erstellen (normalerweise etwa 10).
Rafael, ist das eine Regression bei 2.9.0 Beta oder 2.8.0 Stable?
Zurück zum ersten Beitrag, weiß jemand, woher diese Warnung kommt?
Ich weiß nicht, ob es wirklich etwas ist, das man berücksichtigen sollte, aber persönlich habe ich bei vielen Dingen festgestellt, dass die Leistung bei der Verwendung von Ubuntu 20.04 (Discourse, Webserver, Game-Server) abfällt, selbst wenn ich versuche, auf verschiedene Weise zu optimieren
Derzeit betreibe ich Discourse in einem Droplet für Tests mit den gleichen Merkmalen. Der Wiederaufbau dauert etwa 8-12 Minuten (Ubuntu 18).
Ich glaube nicht, dass der Build bei diesen Warnungen “hängt”. Er kompiliert einfach stillschweigend und die Warnungen werden als Teil des Prozesses ausgegeben.
D.h. die Warnungen oder ihr zugrunde liegendes Problem tragen nicht zur langen Build-Zeit bei.
Wo können wir das verfolgen, @Falco? Vielen Dank, dass Sie uns darüber informiert haben. Ich bin gerade darauf gestoßen und es macht uns hier sehr zu schaffen.
Dies ist eine gigantische Änderung, an der wir seit Jahren arbeiten und die sich in den Endstadium befindet. Währenddessen gibt es eine Periode, in der „die Dinge schlimmer werden, bevor sie besser werden“, und dies ist eine der „schlimmeren“ Nebenwirkungen davon.
Es besteht auch die Möglichkeit, dass wir Personen mit langsamen CPUs erlauben, sich von Source Maps und anderen „nice to have“-Funktionen abzumelden, um ihre Rebuilds zu beschleunigen.
Danke für das Update @Falco Auf einer Quad-CPU mit 8 GB RAM auf Linode, was normalerweise eine fantastische Konfiguration ist, aber jetzt ist es ein Albtraum. Wir haben eine Reihe von Änderungen geplant, müssen aber jetzt warten, bis die Bereitstellung wieder einigermaßen normale Geschwindigkeiten erreicht.
@Falco Ich stelle auch fest, dass die Serverleistung bei den letzten Veröffentlichungen abnimmt, es dauert länger, die Websites zu laden und sie verbrauchen mehr Speicher. Es gab in den letzten 2 Jahren keine Änderungen an meiner Einrichtung (Plugins, Hardware usw.) und die Anzahl der aktiven Benutzer auf der Website ist ebenfalls gleich geblieben. Gibt es eine Möglichkeit, die Website-Leistung innerhalb von Discourse objektiv zu überwachen, die wir dann hier melden können? Im Moment weiß ich nur, dass es über 8 Sekunden dauert, bis die Website beim ersten Öffnen geladen ist (bei früheren Versionen dauerte es immer unter 2-3 Sekunden).
Welche Wiederherstellungszeiten seht ihr? Ich musste gerade wegen einer SMTP-Änderung wiederherstellen, und es hat für eine WINZIGE Website (30 Benutzer, 400 Beiträge) knapp 12 Minuten gedauert.
In diesem Thema geht es um „Build-Zeiten“, nicht um Ladezeiten von Seiten. Wenn Sie über eine Verschlechterung der Seitenantwortzeiten sprechen, eröffnen Sie bitte ein neues Thema dazu mit einigen Daten.
Ich glaube, ich habe herausgefunden, warum das Laden von Seiten so lange dauert. Die Größe der gemeinsam genutzten Datenbank in app.yml wurde auf den gesamten Arbeitsspeicher des Systems gesetzt. Setzen Sie sie auf den Standardwert (25%) zurück, bauen Sie sie neu auf, und es dauert jetzt weniger als eine Sekunde.
Danke für das Update 
Auf einer Quad-CPU mit 8 GB RAM auf Linode, was normalerweise eine fantastische Konfiguration ist, aber jetzt ist es ein Albtraum. Wir haben eine Reihe von Änderungen geplant, müssen aber jetzt warten, bis die Bereitstellung wieder einigermaßen normale Geschwindigkeiten erreicht.