Es gibt Befehle wie rake posts:rebake (also nach einer Migration).
Gibt es weitere Befehle oder andere Maßnahmen, die das Forum beschleunigen? Ich habe den Eindruck, dass es nach dem Wechsel des Hostings mit mehr RAM sogar noch langsamer ist. Mehr GB haben nicht geholfen, obwohl ich es ohne jeglichen Verkehr teste. Ich frage mich, ob es Befehle gibt, die die Datenbank optimieren usw., denn vielleicht liegt es daran, dass das Navigieren über die Links schrecklich lange dauert und sehr langsam ist (1–2 Sekunden). Das ist im Vergleich zu NodeBB zum Beispiel etwas enttäuschend.
Wenn Sie den RAM in Ihrem Server ändern, müssen Sie discourse-setup erneut ausführen, um die Speichereinstellungen anzupassen.
Wie groß ist Ihre Datenbank? Handelt es sich um einen Import oder eine neue Community? Wie schnell ist der Prozessor? Die Single-Core-CPU-Geschwindigkeit ist entscheidend. Sie haben eine SSD und keine mechanischen Festplatten, richtig?
Lightsail richtet sich wirklich an einfache Webanwendungen und Websites.
Sie haben einen CPU-Kern, das bedeutet also 2 Unicorn-Worker, aber Ihre shared_buffers könnten auf 512 MB erhöht werden. Ihre app.yml sollte diesen Kommentar enthalten:
Bei 2 GB empfehlen wir 3-4 Worker, bei 1 GB nur 2
Sie verwenden also doppelt so viele Worker mit der halben empfohlenen Puffergröße.
Drehfestplatten waren das, was vor SSDs kam, obwohl Sie sie vielleicht auch als Festplatten oder HDD kennen. Sie sind für Discourse zu langsam.
Diese Einstellungen werden in der Regel automatisch von discourse-setup basierend auf den Systemanforderungen (Anzahl der CPU-Kerne, RAM-Speicher) zum Zeitpunkt der Ausführung des Skripts festgelegt. Es ist auch sicher, es erneut auszuführen, wenn sich die Serveranforderungen ändern.
Du möchtest sagen, dass es viel besser ist, stattdessen in die günstigste EC2 mit zwei Kernen zu investieren (später möglicherweise mit ELB kombinieren)?
Das sehe ich auch: Jeder Server bei AWS ist ohne HDD.
Es gibt viele Unterschiede bei den AWS-Instanztypen. Einige verwenden EBS-basierte Festplatten, die für den Festplattenzugriff über das Netzwerk laufen, was die Latenz erhöht. Andere verfügen über schnelle lokale NVMe-Laufwerke, aber diese speichern Daten nicht dauerhaft. Zudem gibt es die Instanzfamilien Z und C mit deutlich schnelleren Datenübertragungsraten.
Allerdings wird dadurch alles komplizierter und teurer als ein Digital Ocean Droplet, das für kleine Communities bereits für 5 eine akzeptable Leistung bietet und in seinem für 40 angebotenen CPU-optimierten Paket einen recht schnellen Prozessor bereitstellt.
Übrigens bezieht sich meine Frage auch auf die Befehle selbst. Das heißt, welche Befehle (wie zum Beispiel rake rebake posts) sollte ich ausführen, um Beiträge zu optimieren/neu zu generieren, unnötige Dateien zu löschen usw.?
Warum sollte es einen geheimen Befehl geben, um Dinge schneller zu machen? Warum auf Erden sollten wir standardmäßig einen langsamen Modus verwenden?
Wenn du Leistungsprobleme hast, musst du harte Daten liefern. Was ist der langsame Ablauf, wie groß ist die Community, wie groß ist die Datenbank, hast du versucht, alle Plugins und Themes zu entfernen, hast du versucht, es auf einem $5 DO Droplet laufen zu lassen, usw.
Keine Absicht, jemanden zu beschuldigen, besonders da ich mich selbst nicht damit beschäftigt habe, insbesondere nicht die PostgreSQL-Instanz/Konfiguration… aber Discourse ist verdammt langsam. Nicht sicher, was dafür verantwortlich ist, ich vermute, das Ruby-ORM spielt dabei eine Rolle. Natürlich kann man immer mehr Hardware hinzufügen, mehr SSDs, mehr RAM… bis zu einem gewissen Punkt, aber das ändert nicht den Hauptpunkt: Discourse ist ziemlich anspruchsvoll/langsam, selbst für kleine Installationen wird ein anständiger Host benötigt.
Ich stimme dieser Aussage wirklich nicht zu. Ich kenne mehrere kleine Gemeinschaften, die auf einem 5-Dollar-VPS laufen. Eine langsame Discourse-Installation deutet meist auf eine schlechte Wahl des Hosts oder eine fehlerhafte Konfiguration hin.
Denken Sie daran: Discourse ist keine Website, sondern eine Anwendung. Sobald sie in Ihrem Browser geladen ist, ist der ausgetauschte Datenverkehr minimal.
Wenn Sie den Standard-Installationsleitfaden befolgen, der hier die einzige unterstützte Installationsmethode ist, dann erfolgt die Optimierung für CPU/RAM automatisch. Sie haben uns hier keine Beispiele oder Vergleichswerte gegeben. Ich würde Sie dringend bitten, uns einige konkrete Angaben zu machen.
Ich kann gerne ein paar Benchmarks durchführen. Ich betreibe es auf einer 5-Dollar-Virtualisierung mit wirklich minimaler Hardware nach heutigen Maßstäben – mir ist das bewusst. Ich habe es nicht mit anderen Forumslösungen verglichen, aber ich weiß, was PostgreSQL leisten kann, selbst wenn es in einem Docker-Container auf einer Virtualisierung läuft. Ich habe fast 20 Jahre Erfahrung in der Datenbankentwicklung.
Okay, okay, und ich war ein wenig verstimmt über die Haltung: „Betreibst du es auf Hardware aus dem letzten Jahrhundert, also mit rotierenden Festplatten?"
Ich formuliere es um: „Discourse ist anspruchsvoller als einfachere Systeme.
Was betrachtest du als ausreichende Leistung?
Beschreibe die Szenarien, in denen eine langsame Leistung auftritt.
Wie hast du festgestellt, dass die Discourse-Plattform (oder sogar dein Hosting) die Ursache für die langsame Leistung ist? Dass die Datenbank ein begrenzender Faktor ist usw.
Vielleicht könntest du ein paar Links von webpagetest.org als Ausgangspunkt teilen.
Obwohl das technisch gesehen zutrifft, verfehlt es meiner Meinung nach den Punkt aus der Perspektive des Community-Wachstums und der Benutzererfahrung. Es gibt viel zu sagen für die Menge an Traffic, den unsere Communities über Suchmaschinen anziehen.
Meiner Meinung nach ist es wichtig, dass ihr erster Besuch auf diesem Link schnell lädt.
Und das ist auch so – abgesehen von asset-reichen Communities wie NPN sehe ich kaum Discourse-Communities mit Ladezeiten über zwei Sekunden, und das DOMContentLoaded-Ereignis liegt typischerweise weit unter 1000 ms.
WebPageTest ist ein schlechter Messwert. Öffnen Sie einen Browser, prüfen Sie die Seitenquelle, wechseln Sie zum Tab „Netzwerk“, leeren Sie den Cache und erzwingen Sie einen harten Neuladevorgang. Alle Zahlen liegen direkt vor Ihnen.
Sie behaupten, es gäbe ein Problem, liefern aber keine Beispiele. Es wäre wirklich gut, wenn Sie diese Behauptungen untermauern könnten.
Es ist ein völlig gültiges Werkzeug, das als Ausgangspunkt genutzt werden kann oder um tiefer in spezifische Szenarien (Betriebssystem, Standort, Bandbreite, Latenz) einzutauchen, falls gewünscht. Es ist auch eine praktische Möglichkeit, Ergebnisse aus einem kontrollierten Szenario mit anderen zu teilen.
Der Netzwerk-Tab ist ebenfalls völlig gültig, solange Sie verstehen, dass Sie buchstäblich nur Ihre eigene Erfahrung sehen – höchstwahrscheinlich von Ihrem Desktop über die Verbindung, die Sie gerade nutzen. Es ist ein guter Indikatortest, dauert nur wenige Sekunden und kann Ihnen möglicherweise die Informationen liefern, die Sie benötigen, um für Ihre Besucher zu optimieren – oder auch nicht.
Beides hat seine Berechtigung. Keines davon ist überhaupt ein „schrecklicher Messwert".
@eextra Es ist auch erwähnenswert, dass Sie als Administrator in Discourse einen Zähler für die Antwortzeit sichtbar haben sollten. Außerdem haben Sie die Möglichkeit, über das Admin-Panel NGINX-Leistungsberichte zu protokollieren.
Was ist so schlecht an Websites, die die Geschwindigkeit von Webseiten testen?
Ich wollte meinen Senf dazugeben, da ich sie häufig nutze und hilfreich finde. Besonders diejenigen, die mehrere Standorte abdecken und innerhalb eines Durchlaufs mehrere Tests durchführen.
Interessant finde ich, dass ich bei Optimierungen, die 100–200 ms betreffen, abweichende Ergebnisse von diesen Seiten im Vergleich zu meinem Browser erhalte, obwohl sie bei längeren Zeiten scheinbar genau sind.
Manchmal entscheide ich mich für Optimierungen, die die Geschwindigkeitstest-Seiten zufriedenstellen, denn wenn alle ähnliche Messwerte melden, gehe ich davon aus, dass Google das ebenfalls tut – wobei ich hier auch falsch liegen könnte, da sein Algorithmus proprietär ist.
Ruby ist bekanntlich eine langsame Programmiersprache, Discourse verwendet eine enorme Menge an JavaScript, und es wird kaum bestritten, dass die Ladezeit eines Discourse-Forums beim ersten Aufruf lang ist und die Geschwindigkeit auf mobilen Geräten schlecht ist. Ich finde, die Aussage, dass man mit der richtigen Hardware hervorragende Geschwindigkeitsergebnisse erzielen wird, ist nicht wirklich zutreffend. Schließlich surfe ich gerade auf Meta, und das ist im Vergleich zu einem in Go programmierten Forum tatsächlich langsam, lol. Ich nutze Discourse einfach, weil es gut funktioniert, über hervorragenden Spam-Schutz verfügt, großartige Funktionen bietet und wenig Wartung erfordert. Dass es schnell sei, habe ich jedoch nie angenommen, und die meisten Forum-Besucher betrachten es beim Anklicken des ersten Google-Links auch nicht als „App“.
.
