Wenn ich das Schließen basierend auf dem Datum der letzten Aktivität (anstatt des Erstellungsdatums) durchführen möchte, gibt es eine Variable, die anstelle von created_at verwendet werden kann?
Gibt es eine Möglichkeit, DMs vom Schließen auszuschließen? Ich habe die Abfrage in meiner Testumgebung ausgeführt und festgestellt, dass sie jedes Thema betrifft, egal ob es öffentlich oder privat war. Wir möchten private Nachrichten nach Möglichkeit ausschließen.
Auf unserem Forum haben wir fast 16 Jahre an Inhalten, die wir aus unserer früheren Lösung importiert haben. Wie lange wird die Ausführung der Abfrage dauern (a) und (b) wäre es besser, sie aufzuteilen (z. B. für alles vor 2010, dann für 2011, 2012 usw., bis wir 2023 erreichen) oder sie als einzelne Abfrage auszuführen?
Ich versuche nur sicherzustellen (mit #4), dass wir die Systemleistung nicht zu sehr beeinträchtigen. Ich weiß, dass viel davon abhängt, welche Hardware wir verwenden (die ich nicht wirklich kenne, da wir ein Infrastrukturteam haben, das die Installation selbst durchführt und die gesamte Hardware wartet).
Bei Nr. 2 sieht es mit dem Data Explorer Plugin (von dem ich nichts wusste) so aus, als wäre updated_at wahrscheinlich der Wert, bei dem sich der „Zeitstempel der letzten Antwort“ befindet. Ist das eine korrekte Einschätzung?
Vielen Dank für diesen Hinweis – das ist sehr nützlich für meine ersten drei Fragen, denke ich. Ich würde mich über Klarheit bezüglich updated_at und der Planung, unsere erweiterte Historie von Beiträgen und Themen zu bearbeiten, freuen.
Ich würde auf jeden Fall zuerst mit einem kleinen Stapel testen. Ich habe, äh, eine Community-Seite mit Massenaktionen heruntergefahren und wünschte, ich hätte zuerst eine Teilmenge getestet.
Danke – ich vermutete, dass dies der Fall sein könnte. Es ist gut, eine Bestätigung für den Ansatz zu haben.
Ich denke, ich werde versuchen, eines der letzten Backups zu ziehen und eine Sandbox-Umgebung einzurichten, die von meiner Testumgebung getrennt ist. Ich bin mir nicht sicher, wie das SSO-Teil in dieser Einrichtung funktionieren wird, aber es wäre schön zu sehen, wie die Leistung aussieht, bevor das Produktionssystem beeinträchtigt wird.
Ich werde das berücksichtigen, wenn Sie eine besonders aktive Community haben, wird die Staging-Site die Produktion nicht vollständig simulieren, da die organische Nutzung der Website durch die Nutzer zusätzlich zu den Massenaktionen Auswirkungen hat.
Auf jeden Fall – ich weiß auch den Hinweis auf den Staging-Server-Post zu schätzen – das wird sehr hilfreich sein.
Ja, die Benutzerlast wird wahrscheinlich kein großes Problem sein – unsere Seitenaufrufe pro Tag liegen im Durchschnitt bei etwa 50.000 über alle (Crawler, anonyme und registrierte Benutzer). Das Verständnis der potenziellen Mehrbelastung gegenüber der bestehenden Belastung wird für Planungszwecke nützlich sein.
Ich habe tatsächlich einen Staging-Server eingerichtet (war eigentlich ziemlich einfach - habe nur ein Backup von der Produktion wiederhergestellt und mich über das Admin-Wiederherstellungsverfahren angemeldet, da es nur für OIDC konfiguriert ist). Es sieht so aus, als hätten wir etwa 160.000 Themen, und ein schneller Test in nur einer Kategorie mit etwa 7500 dauerte 6 Minuten auf meinem Testsystem – also etwa 2 Stunden für alle Themen. Die Auswirkungen auf die Systemleistung (überwacht mit htop) schienen hier ziemlich vernachlässigbar zu sein.
Ich bin sicher, wir können eine Zeit mit geringer Auslastung finden, in der der Rake-Befehl ausgeführt werden kann, und wir können Gruppen von Kategorien stufenweise bearbeiten, wenn wir wollen, das wird also sehr gut für uns funktionieren.
Ich schätze all die Tipps und Hilfe – ich habe in den letzten Tagen dadurch viel über die Plattform gelernt.
