rake posts:rebake のようなコマンドがあります（つまり、マイグレーション後など）。
他にも、フォーラムの高速化に役立つコマンドや方法はありますか？RAM 容量を増やした新しいホスティングに変更したにもかかわらず、むしろ遅くなっているような印象を受けます。トラフィックが全くない状態で確認しても、GB の増加は役立ちませんでした。データベースの最適化などを行うコマンドがあるかどうか気になっています。もしかすると、リンク間の移動が非常に遅く（1〜2 秒）、それが原因なのかもしれません。これは、例えば NodeBB と比較すると、やや致命的な問題です。
サーバーの RAM を変更した場合は、メモリ設定を調整するために再度 discourse-setup を実行する必要があります。
データベースのサイズはどのくらいですか？これはインポートですか、それとも新しいコミュニティですか？プロセッサの速度はどうですか？シングルコアの CPU 速度が重要です。HDD ではなく SSD を使用していますよね？
2 GB RAM、1 vCPU、60 GB SSD の Lightsail インスタンスをテスト中
設定は正しいと思います：
UNICORN_WORKERS: 4
db_shared_buffers: "256MB"
詳しく教えていただけますか？
Lightsail は、シンプル Web アプリと Web サイトを主な対象としています。
CPU コアは 1 つしかないため、Unicorn ワーカーは 2 つになります。ただし、shared_buffers は 512MB まで増やすことができます。app.yml には、以下のコメントを含めるべきです。
2GB の場合、3〜4 個のワーカーを推奨。1GB の場合は 2 個のみ。
つまり、推奨されるバッファサイズの半分に対して、2 倍のワーカー数を使用していることになります。
スピニングディスクは、SSD の前に存在したストレージで、ハードディスクドライブ（HDD）とも呼ばれます。Discourse には速度が不十分です。
これらの設定は、通常、そのスクリプトを実行した時点でのシステム仕様（CPU コア数、RAM 量）に基づいて discourse-setup によって自動的に設定されます。サーバーの仕様が変更された場合でも、再度実行しても問題ありません。
最も安価な 2 コア搭載の EC2 に投資する方がはるかに良い、と言いたいのでしょうか（後で ELB と組み合わせることも可能）？
私の確認では、AWS 上のすべてのサーバーは HDD ではありません。
AWS インスタンスタイプには多くの違いがあります。一部のインスタンスは EBS backed ディスクを使用しており、ディスクアクセスのためにネットワークを介するため、レイテンシが高くなります。また、高速なローカル NVMe ドライブを搭載したインスタンスもありますが、データは永続化されません。さらに、データ転送速度が格段に速い Z タイプと C タイプのインスタンスファミリーもあります。
しかし、これらすべてを考慮すると、$5 で小規模なコミュニティに十分なパフォーマンスを提供し、$40 の CPU 最適化プランでは非常に高速な CPU を提供する DigitalOcean のドロップレットよりも、複雑で高価になってしまいます。
「最適化」というのは、具体的にどのオファーを指しているのでしょうか？
ところで、私の質問はコマンド自体にも当てはまります。つまり、投稿を最適化したり再構築したり、不要なファイルを削除したりするために、どのコマンド（例えば「rake rebake posts」など）を実行すべきでしょうか？
そのようなコマンドは存在しません😅。
なぜ速くするための「秘密のコマンド」が存在する必要があるのでしょうか？そもそもなぜデフォルトで低速モードにする必要があるのでしょう？
もしパフォーマンスに問題がある場合は、具体的なデータを示す必要があります。どの処理が遅いのか、コミュニティの規模はどれくらいか、データベースのサイズはどのくらいか、すべてのプラグインとテーマを無効にしてみたか、$5 の DO ドロレットで実行してみたか、などについて教えてください。
先行技術があります 
誰かを責めるつもりはありません。特に、私自身まだ調査していないため、Postgres インスタンスや設定については特にです。しかし、Discourse は非常に遅いです。何が原因かはわかりませんが、Ruby の ORM が一因だと推測します。
もちろん、より大きなサーバー、より多くの SSD、より多くの RAM を追加することはできます。ある程度までは可能ですが、それは本質的な問題を解決しません。Discourse は非常にリソースを要求し、遅いです。小さなインストールであっても、まともなホストが必要です。
本当ですか？その根拠となる数値を示していただけますか？
何と比較して、どのような状況でですか？
Meta は遅いと思いますか？
この意見には強く同意できません。私は、5ドルのVPSで運営されている小規模コミュニティをいくつも知っています。Discourseのインストールが遅い場合、それは通常、ホストの選択が不適切か、設定が誤っていることを示しています。
Discourseはウェブサイトではなく、アプリケーションであることを覚えておいてください。ブラウザに読み込まれた後、やり取りされるデータは最小限です。
ここでサポートしている唯一のインストール方法である標準的なインストールガイドに従う場合、CPUやRAMのチューニングはすべて自動的に行われます。ここでは具体的な例や比較対象を示していないため、具体的な情報を提供することを強くお勧めします。
ベンチマークはできますよ。もちろん、私は現在基準からすると非常に最小限のハードウェアを持つ5ドルの仮想化環境で実行しています。そのことは理解しています。また、他のフォーラムソリューションと比較していたわけではありませんが、Dockerコンテナ内で仮想化環境で実行されていても、PostgreSQLがどの程度の負荷に耐え、どの程度の性能を発揮できるかはよく知っています。データベース開発の経験はほぼ20年あります。
なるほどなるほど、実は「ハードウェアは前世紀のもの、つまり回転型ディスクを使っているのか？」という態度に少し反応してしまいました 
言い直しますと、「Discourseはよりシンプルなシステムよりもリソースを多く要求する」という意味です。
コメントが少しきつすぎましたね、同意します。上記をご覧ください。
「misconfiguration」という言葉の意味を説明いただけますか？それは、クリーンなフォーラムをインストールし、最大1〜2個のプラグインを追加するだけで、実際に何が間違ってしまう可能性があるのかを指しています。いったいどのような設定のことをおっしゃっているのでしょうか？
@eextra いくつか思い浮かぶ点があります…
十分なパフォーマンスとは何だとお考えですか？
パフォーマンスが遅くなっているシナリオを説明してください。
Discourse プラットフォーム（あるいはホスティング自体）が遅延の原因であるとどのように判断しましたか。データベースがボトルネックになっているなど。
もしかすると、webpagetest.org のリンクをいくつか共有していただけないでしょうか。出発点として役立つかもしれません。
技術的にはその通りですが、コミュニティの成長や UX の観点からは本質を捉えていないと思います。検索から引き寄せられるコミュニティのトラフィックの量については、多くのことが言えるでしょう。
私見では、そのリンクへの初めての訪問が素早く読み込まれることが重要です。
実際、NPN のように資産集約型のコミュニティを除けば、Discourse コミュニティの読み込み完了時間が 2 秒を超えることはほとんどありません。DOMContentLoaded も通常 1000ms を大きく下回っています。
WebPageTest はあまり参考にならない指標です。ブラウザを開き、ページソースを検査してネットワークタブに切り替え、キャッシュをクリアしてハードリロードを強制してください。すべての数値が目の前に表示されます。
問題があると指摘はされていますが、具体的な例が示されていません。これらの主張を裏付ける証拠を提供していただけると大変助かります。
これは完全に妥当なツールであり、出発点として、または（OS、場所、帯域幅、遅延など）特定のシナリオをより深く掘り下げる際に使用できます。また、制御されたシナリオからの結果を他の人が確認できるように共有する便利な方法でもあります。
ネットワークタブも同様に完全に妥当ですが、表示されているのは文字通り「あなた自身の」体験であり、おそらくデスクトップから現在接続しているネットワーク経由のものだという点を理解しておく必要があります。これは良いリトマス試験紙であり、数秒で実施できますが、訪問者の最適化に必要な情報を提供してくれるとは限りません。
どちらも価値があります。どちらも「ひどい指標」などではありません。
@eextra にも付け加えると、Discourse の管理者としてログインしている間は、応答時間カウンターを表示しておくべきです。また、管理パネルから NGINX のパフォーマンスレポートをログ出力する機能も備えています。
ウェブサイトの速度テストサイトがなぜ悪いとされるのでしょうか？
私はこれらを頻繁に利用しており、非常に役立っていると感じています。特に、複数の地域からテストを実行し、1回のテストで複数回計測を行うサイトは有用です。
面白いことに、100〜200ms 程度の最適化に関する結果については、これらのサイトとブラウザで異なる値が得られることがありますが、それ以上の時間差については正確なようです。
時には、速度テストサイトで良好な結果が出るような最適化を選ぶこともあります。複数のサイトが似たような計測結果を出している場合、Google も同様の評価をしていると推測するからです（ただし、Google のアルゴリズムは非公開なので、この推測が正しいとは限りません）。
Ruby は famously 低速な言語として知られており、Discourse は膨大な量の JavaScript を使用しています。Discourse フォーラムの初期読み込み時間が長いこと、モバイルでの速度が遅いことは、広く議論されている事実です。適切なハードウェアがあれば高速な結果が得られると人々に伝えることは、必ずしも正確ではないと思います。今まさに Meta を閲覧していますが、Go で書かれたフォーラムに比べると確かに遅いですからね（笑）。私は Discourse を使っていますが、それは機能性、優れたスパム対策、豊富な機能、そしてメンテナンスの容易さからです。速度については、これまで「速い」と考えたことはありませんし、大多数のフォーラム利用者も、Google の検索結果から初めてリンクをクリックしてサイトを訪れる際、それを「アプリ」とは考えていません。