レールコンソールを使用してトピックを一括でクローズする方法についての投稿を見つけました: Auto-close old topics from a migrated forum - #10 by zogstrip
ただし、それについていくつか質問があります。
- これを行うための新しい方法はありますか？
- 作成日ではなく、最終アクティビティ日を基準にクローズしたい場合、
created_at の代わりに使える変数がありますか？
- DM をクローズ対象から除外する方法はありますか？テスト環境でクエリを実行したところ、公開トピックかプライベートトピックかに関わらず、すべてのトピックにヒットしました。可能であればプライベートメッセージを除外したいと考えています。
- 私たちのフォーラムには、以前のソリューションからインポートした 16 年近く前のコンテンツがあります。クエリの実行時間に関して、（a）どのくらいの時間がかかるかを知るにはどうすればよいですか？（b）それを分割して実行する（たとえば、2010 年以前、次に 2011 年、2012 年など、2023 年まで）か、単一のクエリとして実行する方が良いでしょうか？
（#4 で）システムのパフォーマンスに過度に影響を与えないようにしたいだけです。ハードウェアの性能に大きく依存することはわかっています（インフラストラクチャチームがインストールとすべてのハードウェアの保守を担当しているため、実際にはわかりません）。
ご指導いただければ幸いです！
「2番目についてですが、データエクスプローラープラグイン（これは知りませんでした）を使用すると、「最終返信タイムスタンプ」はおそらく updated_at の値になると思われます。これは正確な評価でしょうか？」
このポインターをありがとうございます。最初の3つの質問に非常に役立つと思います。updated_at と、投稿とトピックの拡張履歴の運用計画について、明確化していただけると幸いです。
jericson
(Jon Ericson)
5
まずは少量でテストすることをお勧めします。以前、バルクアクションでコミュニティサイトをダウンさせたことがあり、まずはサブセットでテストしておけばよかったと後悔しました。
「いいね！」 1
ありがとうございます。その可能性が高いと思っていました。アプローチについて確認できてよかったです。
最近のバックアップの1つを取得し、テスト環境とは別のサンドボックス環境をセットアップすることを検討しようと思います。そのセットアップでSSOがどのように機能するかはわかりませんが、本番システムに影響を与える前にパフォーマンスがどのようになるかを確認できると良いでしょう。
jericson
(Jon Ericson)
7
それは良いアイデアですね：
特にアクティブなコミュニティがある場合、ステージングサイトは、大量のアクションに加えて、人々がサイトをオーガニックに使用することによる影響がいくつかあるため、本番環境を完全にシミュレートできないことに注意しておきます。
もちろんです。ステージングサーバーの投稿へのポインタもありがとうございます。大変参考になります。
はい、ユーザー負荷は大きな問題にはならないでしょう。ページビューは、クローラー、匿名ユーザー、登録済みユーザーをすべて含めて、1日あたり平均約50,000件のようです。既存の負荷に対する潜在的な負荷増加を理解することは、計画の目的で役立ちます。
ステージングサーバーをセットアップしました（実際には非常に簡単でした。本番環境のバックアップを復元し、OIDCのみに設定されているため、管理者リカバリ手順を使用してログインしました）。トピックは約16万件あり、約7500件のカテゴリのうち1つをテストしたところ、テストシステムで6分かかりました。すべてのトピックで約2時間かかる計算になります。システムパフォーマンスへの影響（htopで監視）は、ここではほとんど無視できる程度でした。
rakeコマンドを実行できる利用頻度の低い時間帯を見つけ、必要に応じてカテゴリのグループをステージングできるので、非常にうまく機能するはずです。
この数日間でプラットフォームについて多くのことを学びました。ヒントや助けに感謝します。
system
(system)
クローズされました:
10
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.