Ich habe versucht, danach zu suchen, aber nichts kürzlich Gepostetes gefunden, also dachte ich, ich frage, um festzustellen, was normal und zu erwarten ist.
Ich komme gerade von anderen Foren, und der erste Seitenaufruf ist einigermaßen schnell, aber bei Discourse lädt die Seite, aber ich sehe einen sich drehenden Kreis, während er darauf wartet, dass die Seite gerendert wird – ich bin mir nicht sicher, ob das eine Serververzögerung oder eine Client-/JS-Verzögerung beim Erstellen der Seite basierend auf dem zurückgegebenen Serverergebnis ist.
Die Verzögerung beträgt etwa 5-10 Sekunden – aber im Allgemeinen ist die Leistung danach in Ordnung.
Wenn das Problem wahrscheinlich beim Server/Hosting liegt, was ist das normale Problem – da die Metriken bei allem niedrig aussehen. CPU, Festplatte und Speicher scheinen nicht ausgelastet zu sein, daher bin ich mir nicht sicher, wo ich $$ investieren soll, wenn das Ergebnis nicht wirklich mit dem Server zusammenhängt. Irgendwelche Tipps zur Überwachung oder Beobachtung von Metriken, die zeigen können, wo Discourse seine Zeit mit Warten auf Dinge verbringt?
Neueste 2.8.x und nur etwa 30 Benutzer. Ich betreibe es auf einem Dual-Core-vCPU mit 2 GB RAM und SSD-Festplatte.
Wie erwähnt, zeigen alle Metriken auf dem Server keine Auslastung an. Daher verstehe ich nicht, warum es 5 Sekunden dauert, bis die Seite vollständig gerendert ist.
Gibt es also nichts zu überprüfen oder zu überwachen, nur installieren und hoffen, dass alles in Ordnung ist?
Eigentlich ist es eher so, dass der Server kalt wird und ich nur einen Seiten-Refresh anfordere, der schon eine Weile nicht mehr durchgeführt wurde – gehen die Backend-Teile in den Ruhezustand oder so, dass bei seltener Nutzung die erste Person wahrscheinlich etwas länger als üblich warten muss?
Wenn Sie von 30 Benutzern sprechen, meinen Sie gleichzeitige Benutzer oder ist das die gesamte Benutzerbasis?
Wenn es sich um 30 gleichzeitige Benutzer handelt, dann ist Ihre Spezifikation möglicherweise etwas niedrig.
Wie hoch ist der durchschnittliche Speicherverbrauch? 30-50-80 %???
Ich habe mir gerade die Geschwindigkeits- und Leistungscharts von G Analytics angesehen und festgestellt, dass sich seit dem Wechsel von 2.2 auf 2.9 etwas verschlechtert hat, aber ich muss mir das genauer ansehen. Ich erlebe keine spürbare Verlangsamung, im Gegenteil, es scheint schneller zu sein. Was weiß ich also oder was weiß G Analytics, hm?
Ich habe auch von der 10.000-Beitrags-Obergrenze pro Thema gelesen, dass es, wenn man viele Beiträge hat, meiner Meinung nach das Ganze in den Speicher laden muss, bevor es angezeigt wird, und dies wird beim ersten Ansehen als Langsamkeit wahrgenommen.
Ich stelle fest, sobald es etwas geladen hat, ist alles schnell. Ich bin kein Experte, aber es könnte auch am Browser liegen und an allen möglichen anderen Tricks, die angewendet werden, um das Discourse-Erlebnis zu ermöglichen.
Ist dies ein VPS bei einem Hoster oder etwas anderes? Wie wurde es installiert? Zu wissen, welche 2vcpu es sind, ist hilfreich – nicht alle Prozessoren sind gleich.
Befindet sich etwas zwischen der Instanz und den Clients? Ein Reverse-Proxy oder etwas wie CloudFlare?
Ich habe endlich die Entwicklertools geöffnet und sehe einige Fehlermeldungen … sieht so aus, als ob a) Schriftarten fehlen oder nicht gefunden werden und b) die IP anstelle des korrekten FQDN verwendet wird - wobei ich mir nicht sicher bin, ob die IP korrekt ist
Das FetchEvent für "https://35.212.139.150/fonts/Roboto-Regular.ttf?v=0.0.9" ergab eine Netzwerkfehlerantwort: das Promise wurde abgelehnt.
Promise.then (async)
(anonym) @ Router.mjs:60
Das FetchEvent für "https://35.212.139.150/fonts/Roboto-Bold.ttf?v=0.0.9" ergab eine Netzwerkfehlerantwort: das Promise wurde abgelehnt.
Promise.then (async)
(anonym) @ Router.mjs:60
NetworkFirst.mjs:167 Uncaught (in promise) no-response: no-response :: [{\"url\":\"https://35.212.139.150/fonts/Roboto-Regular.ttf?v=0.0.9\"}]
at a.makeRequest (https://community.hubivue.com/javascripts/workbox/workbox-strategies.prod.js:1:2145)
makeRequest @ NetworkFirst.mjs:167
color_definitions_light_4_1_530ebcc4a553d42866a6f343d784841cf5c0b816.css:1 GET https://35.212.139.150/fonts/Roboto-Regular.ttf?v=0.0.9 net::ERR_FAILED
NetworkFirst.mjs:167 Uncaught (in promise) no-response: no-response :: [{\"url\":\"https://35.212.139.150/fonts/Roboto-Bold.ttf?v=0.0.9\"}]
at a.makeRequest (https://community.hubivue.com/javascripts/workbox/workbox-strategies.prod.js:1:2145)
makeRequest @ NetworkFirst.mjs:167
color_definitions_light_4_1_530ebcc4a553d42866a6f343d784841cf5c0b816.css:1 GET https://35.212.139.150/fonts/Roboto-Bold.ttf?v=0.0.9 net::ERR_FAILED
Weit gefehlt … Ich habe die Schriftarteinstellungen auf die Standardwerte (d. h. Arial) zurückgesetzt und alles funktioniert einwandfrei. Sieht nach einem Fehler aus oder etwas ist mit der Auswahl von Schriftarten in der Einrichtung schiefgelaufen. Fall abgeschlossen und ich werde vorerst mit Arial leben
Es hängt davon ab, wie sie auf die Verwendung des Hostnamens umgeschaltet haben, nachdem sie versucht hatten, die IP-Adresse zu verwenden.
Wurde dies gemäß den Schritten in der Standardinstallation durchgeführt? Ich würde mich mit demjenigen unterhalten, der die Instanz eingerichtet hat, um herauszufinden, was getan wurde. Die IP-Adresse wird möglicherweise noch an anderer Stelle referenziert.
Gibt es einen Befehl, um die Installation zurückzusetzen oder dies zu beheben? Es scheint unsinnig, dass man den Hostnamen nie wieder ändern kann. Ist diese Einschränkung absichtlich?
Beachten Sie, dass die Leistung jetzt in Ordnung ist, da die Basisschriftarten verwendet werden – die Probleme scheinen mit der Verwendung der Google Roboto-Schriftarten zusammenzuhängen.
Es kann nicht schaden, es zu versuchen, aber wenn Sie keine Informationen über die Historie der Instanz haben, können wir nicht einmal bestätigen, ob Sie eine offiziell unterstützte Installation ausführen.
