Wir haben 5 Millionen Beiträge, und die Suche ist ziemlich flott. Wir hosten auf 6 gemeinsamen vCores eines 2,8-GHz-Xeon-E5-2680 mit 16 GB RAM und SSD-Speicher. Allerdings habe ich keine Metriken darüber, wie viele gleichzeitige Beiträge unsere Nutzer initiieren; es könnte zu Sperrproblemen kommen.
Das Veröffentlichen hingegen ist oft recht langsam. Ein Beitrag kann 6 bis 7 Sekunden brauchen, um durchzugehen. Discourse blockiert jedoch nicht, während es im Hintergrund arbeitet, was die Benutzererfahrung nicht beeinträchtigt.
Ich denke, dass dies bei jedem Thema mit Hunderten oder Tausenden von Beiträgen höchstwahrscheinlich der Fall ist. Bei kurzen Themen sollte dies nicht so sein.
Ich erinnere mich, dass @Wingtips Forum eine Menge sehr langer Themen hat.
Beziehen sich die 6–7 Sekunden für die Post-Zeiten speziell auf Mega-Themen? Wenn du auf ein Thema mit 100 Antworten antwortest, dauert es dann auch 6–7 Sekunden?
Ich konnte es gerade nicht reproduzieren – das langsame Posten tritt nur gelegentlich auf. Es scheint nicht mit der Anzahl der Beiträge im Thread zusammenzuhängen. Vielleicht liegt ein Sperrproblem vor, weil jemand gleichzeitig postet, oder so etwas.
7 Beiträge = sehr schnell, ungefähr genauso schnell wie hier auf Meta
500 Beiträge = vielleicht etwas langsamer, aber nicht allzu schlimm. Vielleicht 1,5 Sekunden?
16k Beiträge = scheint ungefähr genauso schnell zu sein wie bei 500
Und ich bin der Meinung, dass die Leistung ebenfalls beeinträchtigt wird, wenn viele Nutzer auf ein riesiges Thema zugreifen, was den gesamten PG-Server durch Warteschlangen von Anfragen verlangsamt.
Wie mutig fühlst du dich gerade? Wäre es dir recht, wenn du kurz den mini_profiler aktivierst? Er zeigt dir dann die Ausführungszeiten an der Seite an, sodass wir herausfinden können, welche Abfrage bei dir Probleme macht!
Wie stark wirkt sich die Aktivierung auf die Gesamtleistung aus? Und kann sie ohne einen kompletten Neuaufbau der Site aktiviert werden? Seit der Umstellung auf PostgreSQL 12 ist es mir nicht gelungen, einen Neuaufbau erfolgreich durchzuführen, selbst nicht durch die Einstellung, bei PostgreSQL 10 zu bleiben.
Sie müssen Ihre E-Mail-Adresse als Entwickler-E-Mail in der Datei app.yml festlegen. Sie können dies ohne Neuzusammenstellung anwenden, indem Sie den Container zerstören und neu starten. Wenn Sie Änderungen am Container vorgenommen haben, z. B. durch ein Upgrade mit Discourse Docker, gehen diese verloren.
Sie können auch config/discourse.conf im Container bearbeiten und dann
Da Neubuilds fehlschlagen, mache ich mir Sorgen, dass ich bei der Zerstörung des Containers komplett aufgeschmissen bin. Gestern hatte ich so viele Fehler beim Versuch des pg12-Upgrades, dass ich mich wirklich nicht wohl fühle, Änderungen vorzunehmen, bis ich die Gewissheit habe, die Website nicht für einen längeren Zeitraum offline zu legen.
Nun, kostenlose Ratschläge sind genau so viel wert, wie man dafür bezahlt, aber es ist ziemlich sicher, Folgendes zu tun:
cd /var/discourse
./launcher enter app
vi config/discourse.conf
# Bearbeiten Sie in vi die Zeile developer_emails, um Ihre E-Mail-Adresse einzutragen, und beenden Sie vi
sv unicorn restart
# Panik für die 30–90 Sekunden, die der Webserver zum Neustarten und zum Bereitstellen von Seiten benötigt
Sie können auf diese Weise jedoch immer noch Dinge beschädigen. Ich denke, es ist möglich, diese Konfigurationsdatei so zu manipulieren, dass Discourse nicht startet.
Ist das das, was Sie benötigten? Dies wird in einem Thread mit 16.000 Beiträgen gepostet. Das erschien wie eine normale Posting-Zeit, nicht besonders langsam.
Toll! Jede wesentliche Verbesserung der Posting-Zeit wird unsere Nutzer wirklich freuen – das ist aktuell das am häufigsten beklagte Thema. Obwohl ich keinen Zweifel daran habe, dass sie kurz darauf etwas anderes finden werden, worüber sie meckern können.
Wenn es dich ein wenig tröstet, habe ich mich auch über diese Abfrage beschwert, denn ich habe hier auf Meta so viele gelesene Zustände. Wir verrichten sinnlose Arbeit, um bei jeder Antwort Dinge zu zählen…
Bei unserem Testimport aus einer anderen Software hatten wir ein Thema mit etwas mehr als 200.000 Beiträgen, und ich konnte problemlos darin posten. Es muss also nicht die Größe des Themas ausschlaggebend sein, sondern vielmehr der Benutzer, der den Beitrag erstellt.
