10分遅延の回避策を試みています

ガルフコーストの天気予報サイトでwp-discourseプラグインを使用する予定です。このサイトは通常、1日あたり約1万〜2万ページビューですが、悪天候時には1日あたり150万〜200万ページビュー、約50万〜70万人の訪問者に達することがあります。サイトとそのホスティング戦略は、いくつかの悪天候イベントを通じて実証されており、慎重な設計とCloudflareの多大な協力のおかげで、プレッシャー下でもうまく機能しています。

サイトのユーザーは、ネイティブのWordPressコメントによる低摩擦のコメント体験に慣れているため、ユーザーインターフェースのスタッフは管理する準備ができていますが、「ディスカッションを続ける…」リンクをクリックすることに慣れるなど、多少の調整が必要になります。

しかし、コメントの投稿からWordPressの日次投稿ページに表示されるまでの10分間の遅延は、彼らは容認しません。ネイティブのWPコメントが投稿直後に表示されるのと同じように、新しいコメント(設定された制限まで)を投稿時にホームページに即座に表示することを望むでしょう。

nginxのfastcgiキャッシュ、WordPress、またはブラウザキャッシュが、投稿後にリフレッシュしたときに新しいコメントが表示されるのを妨げないように、組み込みオプションをいじくり回した結果、これを軽減し、新しく投稿されたコメントがリフレッシュ時にWordPress側に表示されるように、次の2つのmuプラグインを追加しました。

wp-discourse-transient-killer.php
wp-discourse-cache-header-fix.php

これにより、問題が解決しました。WordPressで作成されたDiscourseスレッドへの新しい投稿は、リフレッシュ時にWordPress投稿の下に即座に表示されます。

しかし、これは私の能力の限界に近づいています。これを実行することで、何を壊したり、台無しにしたり、損なったりしているのでしょうか?

コメントのエンドポイントが、埋め込まれたDiscourseコメントを含む日次天気予報ページをチェックする訪問者によって叩かれることによる、ウェブホストへの追加負荷については気にしません。それは、お金をかけることで解決できる問題です。私の主な要件は、コメントを投稿したときにホームページにコメントが即座に表示されない理由を尋ねる2万人以上のユーザーからのメールを回避することです。

これは正しいアプローチですか?私がやっていることは賢明ですか?予期しない追加のセキュリティまたはパフォーマンスの問題を引き起こしますか?基本的に、これを実行することで台無しにしていますか?

ありがとうございます :slight_smile:

Hmm、これがなぜ機能するのか分かりません。なぜなら

そしてあなたのプラグインは

add_action( 'wpdc_after_webhook_post_update', function( $topic_ids ) {
    foreach ( (array)$topic_ids as $topic_id ) {
        delete_transient( 'wpdc_comment_html_' . $topic_id );
    }
}, 11 );

アクションに渡される (Wordpress) $post_id と、トランジェントキーとして機能する (Discourse) topic_id を混同していませんか?

あなたのプラグインは次のようになっていると予想していました。

add_action( 'wpdc_after_webhook_post_update', function( $post_ids) {
    foreach ( (array)$post_ids as $post_id ) {
        $topic_id = get_post_meta( $post_id, 'discourse_topic_id', true );
        delete_transient( 'wpdc_comment_html_' . $topic_id );
    }
}, 11 );

逆に、これが機能すると言っていますか? :thinking:

@Lee_Ars さん、まずコメントのWebhookが設定されているか確認していただけますか?

これは次のように機能します。

  1. Discourseに新しい投稿があります。
  2. WebhookペイロードがWordPressに送信されます。
  3. WP Discourseは、投稿のコメント数を更新し、wpdc_sync_post_commentsというカスタムフィールドを設定します。
  4. wpdc_sync_post_commentsが設定されている場合、WordPressの投稿が読み込まれると、同期期間(つまり10分の遅延)に関係なく、Discourseのコメントが同期されます。

キャッシュについて説明する前に、まずそれが機能していることを確認したいと思います。もし機能している場合は、「Verbose Webhook Logs」をオンにして、Discourseで新しい投稿があったときにWebhookリクエストを受信していることを確認していただけますか。

「いいね!」 1

Angusさん!はい、WP側で「Sync Comment Data」Webhookオプションが有効になっており、Discourse側でWebhookを作成し、pingも成功しています。WPプラグインのログには、適切なタイムスタンプで comment.INFO: sync_comments.success メッセージが表示されています。

[2025-07-07 14:16:38] connection.INFO: check_connection_status.successful_connection
[2025-07-07 14:16:38] connection.INFO: check_connection_status.valid_scopes
[2025-07-07 20:11:31] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:25:03] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:32:14] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:44:15] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:00:39] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:01:42] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:15:40] comment.INFO: sync_comments.success {"post_id":786}

しかし、これらの成功メッセージが表示されていても、既存の訪問者(少なくとも私自身が、macのfirefox/safari/chrome、win10 PCのfirefox/chrome/edge、iosのsafariで複数回テストした限りでは)は、cache-control ヘッダーがゼロ以外の値に設定されたキャッシュされた /wp-json/wp-discourse/v1/discourse-comments エンドポイントを取得し続けています。ChromeでCtrl+Shift+F5(または他のブラウザで同等の操作)を実行して、リフレッシュ時にローカルキャッシュをバイパスすると、すべて正常に機能し、新しい投稿が表示されます。

mu-plugins を配置すると、そのエンドポイントは cache-controlno-store no-cache などに設定され、問題の動作は現れません。通常の更新ボタンでWP投稿を単に表示または更新すると、新しい埋め込みコメントが表示されます。

Webhook の詳細なログをオンにしてテスト投稿をしましたが、新しい投稿を作成するとすべて問題ないように見えます。

webhook_topic.INFO: update_topic_content.update_post_metadata_success {"post_ids":"786"}

すべてが正常に機能しているように見えますが、元の問題の動作がなぜ発生したのか、または私の側で何か見落とした問題に起因するのか、まだよく理解できていません。(十分にあり得ます!)

ああ、すみません、私がそれを台無しにしたのは確かだと思います。昨日は長い一日でしたし、言ったように、私の能力の限界に近づいています。確かに何かをしていましたが、今では「修正された」動作が、単に新しい方法で壊れているだけなのかもしれないと思っています。(「transient killer」プラグインを正しい引数を使用するように更新しました。ありがとうございます!)

ありがとうございます。もう一点だけ確認させてください。このWP Discourseの設定(「コメント」の中にある)はオンになっていますか?

「Cache Comment HTML」設定を有効にしても無効にしても試しましたが、問題の動作には影響がないようです。現在は無効にしていますが、トラブルシューティングに役立つように設定を変更することは可能です。

設定が無効の場合、トピックID/投稿IDの混同に気づくことはありません。なぜなら、そのプラグインはその場合何も行わないからです。キャッシュなし → 間違ったキャッシュを削除しても問題ありません。

設定が有効な場合、プラグインが正常に機能しないことに気づくはずです。

つまり、トラブルシューティングを行いたい場合は、設定を有効にする必要があります。

「いいね!」 1

まず、お客様のケースの対策として、以下を推奨します。

  1. キャッシュコメントHTMLを無効にする。
  2. Richardが指摘しているように、現在何も機能していない https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt プラグインを削除する。

これで問題が解決しない場合は、他のキャッシュ形式の問題となります。次に回答すべき質問は以下の通りです。

  1. WordPressでどのようなキャッシュソリューションを使用していますか(お客様自身、またはホスティングプロバイダー)。
  2. https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt が問題を解決する場合、その特定の動作は、1で適用されているキャッシュをどのように無効化しますか。

wp-discourse-cache-header-fix を見ると、修正の1つが load-comments.js 用であることがわかります。この設定を有効にしていますか?

これは、nginx+php-fpm 8.3 でセルフホストされた WP で、動的コンテンツには nginx fast-cgi キャッシュ、オブジェクトキャッシュには Redis を使用しています(object cache drop-in がアクティブです)。CDN、CF、オンボックスの Varnish、または nginx の fast-cgi キャッシュ以外のローカルキャッシュはありません。nginx の fast cgi キャッシュをダンプしても(rm -rf /etc/nginx/cache/* を実行して積極的に)、問題の動作には影響しません。キャッシュディレクトリを空にして nginx と php-fpm の両方を再起動しても、古い結果が提供されます。

現在 Ajax コメントの読み込みが有効になっているのは事実ですが、これも無効にして(念のため nginx のキャッシュをダンプして nginx と php-fpm を再起動しても)、問題の動作には影響しませんでした。ブラウザは古いコメントを取得し続けています。

オプションを切り替え、transient-killer を削除しました。問題の動作に変化はありません。

適用される効果は、キャッシュ時間が指定された cache-control ヘッダーの代わりに、no-cache ヘッダーを供給することのようです。それがないと、私のブラウザは wp-json/wp-discourse/v1/discourse-comments エンドポイントの古いキャッシュバージョンをディスクキャッシュから提供しようとするようです。指摘したように、no-cache リフレッシュを強制するには Shift-Ctrl-F5(または同等の操作)が必要です。

問題の動作は、永続的なサーバーキャッシュではなく、ブラウザ側にあるようです。アクセスできるすべての OS のすべてのブラウザがそれを実行しています。

承知しました。念のため100%明確にしておきます。以下の状態の場合、

  • 動作確認済みのコメントWebhook
  • コメントHTMLのキャッシュをオフ
  • AJAX読み込みをオフ
  • CDNなし
  • CloudFrontなし
  • WordPressキャッシュプラグインなし
  • PHPログに関連する警告やエラーがない

動作していないと確信していますか?

その設定で動作しない場合、詳しく確認せずに少々途方に暮れています。デフォルトでは

  • AJAX読み込みをオン
  • あなたの wp-discourse-cache-header-fix.php の修正

これらがあなたにとって機能していたと思われるものです。その方法で動作するのであれば、それを選ぶべきです。

参考として、現在のプラグイン設定のスクリーンショットの簡単なImgurギャラリーを以下に示します

CDN、Cloudfront、またはCloudflareのいずれもないことを確認してください。Nginxヘルパー(必要に応じてWPがNginx fast-cgiキャッシュを無効化するのを支援するため)以外のキャッシュプラグインもありません。

php-fpmまたはNginxのエラーログに関連するものが何も表示されないことも確認してください。

ああ、そうだったらいいのに。これは約30時間、睡眠時間を除いて取り組んでいます。少し目が回っているかもしれません、へへ。

うん、わかるよ。1日くらい休みを取って。明日、あなたの環境をコピーして、問題を再現してみます。

「いいね!」 2

もし私が解決策を見つけられず、もしよろしければ、トラブルシューティングのために一時的なローカルアクセス(WPブログ、ディスコース、および/または基盤となるホストへのアクセス)を許可できます。決して無料の労働を得ようとしているわけではありません。実際にここに時間を費やす必要がある場合は、サービスに対して喜んでお支払いします。

承知いたしました。問題の再現を試みた(そして失敗した)私のビデオはこちらです。

次に試していただきたいのは、こちらのフィルターです。

@angusさん、ありがとうございます。再現しないということは、私が何か間違っているということなので、むしろ安心しました。実際に何か問題があるわけではないのですね :smiley:

トラブルシューティングのための時間が取れたら、今日そのフィルターを追加して、また報告します :+1:

「いいね!」 1

1か月以上経ってからループを閉じるために返信します。本番環境へのデプロイ(prod site, discourse embed を使用した実際の prod site の投稿, 実際の discourse forum)でまだ奇妙な現象が発生していますが、すべて管理可能です。残りのレイテンシ/遅延の問題は、WordPress + Discourse + Cloudflare という複雑なレイヤーケーキと、実際の嵐によって発生するトラフィックの嵐の間、これらすべてを運用し続けるための私の積極的なキャッシュ戦略に起因すると考えます。

返信していただきありがとうございます、@angus <3

「いいね!」 1

何度もこの件をぶり返してしまい申し訳ありませんが、フォローアップとして、問題の原因を見つけたことをご報告します!いつものように、私のくだらないミスでした。

ごく簡単に言うと、PHPの一般的なロケーションブロックの詳細を /etc/nginx/snippets/ のスニペットに保存しているので、複数のvhostファイルで重複させることなく含めることができます。そのスニペットを確認してからずいぶん長い間(おそらく数年)経っていましたが、案の定、そのロケーションブロックから出てくるものすべてに適用されていた、不適切な add_header Cache-Control "public, max-age=7200"; がありました。

そこで、それを削除し、すべてのキャッシュレイヤーをフラッシュしたところ、問題の動作は消えました。

私のせいでまたDiscourseの問題になってしまいましたが、時間を割いて私と一緒に作業してくださった@angusさん、本当にありがとうございました :people_hugging:

「いいね!」 3

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.