すべてのメンバーが最初の投稿を購読するように自動的にサブスクライブされる #Announcements カテゴリがあります。
これにより、そのカテゴリへの投稿の公開を特定の時間/日付にスケジュールすることができます。
次に、そのアナウンスメントが約25,000人のメンバーにメールで送信されます。
私たちが直面している問題は、メールの送信に1時間以上かかることです。これは時間的制約のあるアナウンスメントには理想的ではありません。
Sidekiqを監視すると、「Scheduled」カウンターが個々のメールを1つずつ積み上げていくのがわかります。約20,000に達すると、それらを「Enqueued」タブに移動し、最終的に送信が開始されます。
このプロセスをスピードアップすることはできますか？
時間的制約のあるメールは、現在の送信速度の約100倍速で送信できると嬉しいです:blush:
このディスカッションは、DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE の設定方法を説明しており、ダイジェストのグローバル制限を定義しているため、参考になるかもしれません。
今晩、時間を計ってみました。
18:30 に #Announcements カテゴリに公開する投稿をスケジュールしました。
18:40 には、Scheduled キューに 15,000 件のメールがありました。
18:45、つまり投稿から 15 分後には、Scheduled キューに 22,000 件のメールがありました。
18:48 に、それらのメールが徐々に Enqueued キューに移動し始めました。
18:51 には、まだ移動中でした。
19:03 には、メールが送信され始めていました。
19:10 までには、残りのメールは 10,000 件でした。
19:27 には、残りのメールは 569 件でした。
そして 19:29 には、すべてのメールが送信されました。
ということで、22,000 件のメール通知を送信するのに丸 1 時間かかりました。
ここでボトルネックとなっている箇所を特定するのを手伝っていただけますか？
現在の 1 時間あたり 22,000 件というレートよりも速くこれらのメールを送信できるようになりたいです。
勘に頼った推測ですが、インフラの負荷の問題の可能性はありますか？
ここには2つのことが起こっています。
最初の点については、100%確信はありませんが、email_time_window_minsを短くすると、通知がより早くキューイングされると考えています。
メールジョブがscheduledになると、Sidekiqワーカーがそれらを1つずつ処理します。Sidekiqワーカーを増やす（サーバー容量に応じてDISCOURSE_SIDEKIQ_WORKERSを5から10、15、または20に設定する）と、より多くのジョブが同時に処理されるため、キューが2倍/3倍/4倍速く空になります。
バックエンドの最も細かい部分についてはわかりませんが、email_time_window_mins は最初のメールが送信される前の遅延設定にすぎません。この間、メールを受信するように設定されているユーザーは、その期間内にアクティブである場合、メールを「放棄」する可能性があります（公式用語：メールスキップ。スキップ理由：ユーザーが最近アクティブでした）。
デフォルトの遅延は10分です。つまり、投稿が10分間公開されてから、メールが送信されます。
Richie の問題は、最初のメールと最後のメールの間の時間差、つまり1時間の遅延です。これはおそらく送信する必要のあるメールの量が膨大であるためですが、これも確実には言えません。
上記の Сetting を変更しても、最初のメールの送信が速くなるだけで、22,000通のメール全体の完了期間には影響しません。
インフラストラクチャの能力に依存しますが、推奨される設定は何でしょうか？
高い設定は、負荷などの点でサーバーの問題を引き起こす可能性がありますか？
「サーバーが処理できる数だけ」。
これは完全にOPのサーバー容量に依存します。多すぎると遅くなり、少なすぎると処理に時間がかかります。
CPUグラフが40％に達していることを考えると（これは単一のCPUまたは総容量のどちらかですか？）、リスク許容度に応じて、2倍（控えめ）または3倍（積極的）に増やしてみて、何が起こるかを確認することから始めるのが良いでしょう。
素晴らしい洞察をありがとうございます 
DISCOURSE_SIDEKIQ_WORKERS は 5 の倍数である必要がありますか？例えば 7 に設定できますか？
app.yml にそのパラメータ設定がないため、デフォルトで 5 になっていると仮定します。
既存のユニコーンワーカー設定の下にその設定を作成し、再構築することはできますか？
例：
expose:
- “443:443”
env:
UNICORN_WORKERS: 8
DISCOURSE_SIDEKIQ_WORKERS: 7
それだけで簡単ですか？
DISCOURSE_SIDEKIQ_WORKERS パラメータが現在存在しない場合、app.yml に行うべき正しい変更であることを誰か確認していただけますか？
はい、AIボットに簡単に問い合わせたところ、そう信じています。
@TempAccount さん、ありがとうございます。
興味深いことに、DISCOURSE_SIDEKIQ_WORKERS は、meta 全体で 11 回しか出現しません。
https://meta.discourse.org/search?q=%22DISCOURSE_SIDEKIQ_WORKERS%22%20order%3Alatest_topic
…そして、そのうちの1つはこのトピックにあります 
はい、これは正しいです。
ほとんどの設定は、この方法で上書きできます。デフォルト値は、discourse_defaults.conf から取得されます。
@supermathie ありがとうございます。
これで app.yml は以下のようになります。
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## 同時に処理できるWebリクエスト数はいくつですか？メモリとCPUコアに依存します。
## ブートストラップによって検出されたCPUに基づいて自動的に設定されますが、上書きすることもできます。
UNICORN_WORKERS: 8
## 2025/10/04 に追加
## REF: https://meta.discourse.org/t/is-there-a-way-i-can-send-email-notifications-faster/383103/12
DISCOURSE_SIDEKIQ_WORKERS: 7
週の後半に再構築して、メール送信の時間を計測します 
変更が反映されたことを確認するために、この Threads の値は 5 から 7 に増えるはずですか？
@Richie 問題は解決できましたか？
ご連絡ありがとうございます。
残念ながら、そうではありません。
スレッドを5から8に増やしましたが、メールの送信には最初から最後まで1時間近くかかっています。
処理能力全体が40%増加すると予想されます。
ジョブがキューに入れられたとき、7/7の利用率が見られますか？
また、処理中のサーバー負荷を確認し、可能であればさらに引き上げることをお勧めします。
おーーーー、ちょっと待って。Discourseは自分で制限をかけているのですか？
CPU使用率を制限する設定を見逃しましたか？？ 
それ自体を制限しているわけではありませんが、各sidekiqワーカーは一度に1つのジョブを処理するため、22,000件のメールが送信待ちの場合、それらのうち7件が同時に処理されます。
馬鹿げた話ですが、並列ワーカーの数を1000に設定しても、サーバーが追いつかない可能性が高いです。したがって、すべてのニーズに適した数値を見つけることが重要です。
