Umgebung: Selbst gehostetes Discourse auf AWS EC2 mit der Ubuntu 24.04 AMI. Der Host ist ein r7g.large mit 2x vCPUs und 16 GB RAM. Discourse hat die Version 3.6.0.beta1-dev (db974047e4) und wird regelmäßig aktualisiert. WordPress hat die Version 6.8.2 und das wp-discourse-Plugin die Version 2.5.9. Sowohl WordPress als auch Discourse werden über Cloudflare „orange-cloud“ weitergeleitet.
Aktuelle wp-discourse-Einstellungen: Ich zeige Discourse-Kommentare für alle Themen an und habe „Kommentare mit Ajax laden“ aktiviert. (Sowohl die Leser als auch die Besitzer der WordPress-Website möchten, dass neue Kommentare so schnell wie möglich unter den WP-Beiträgen angezeigt werden. Daher möchte ich gemäß den Anforderungen der Besitzer „Kommentare mit Ajax laden“ aktiviert lassen.)
Was ich sehe: Im Allgemeinen funktioniert wp-discourse hervorragend. Wenn ein Leser einen WP-Beitrag besucht, fordert sein Browser /wp-json/wp-discourse/v1/discourse-comments?post_id=XXXXX an, wobei XXXXX die erwartete Beitrags-ID ist, und die Kommentare werden ohne Probleme geladen. Neue Kommentare erscheinen auf der WordPress-Seite innerhalb weniger Sekunden, nachdem sie in Discourse gepostet wurden.
Besucherbrowser senden jedoch auch einen Aufruf an dieselbe discourse-comments-URI, wenn sie irgendeine WordPress-Adresse auf der gesamten Website besuchen. Die Homepage der Website, Kommentararchive, die Über-uns-Seite, die Kontaktseite, Autoren-Bio-Seiten, statische Seiten, Suchseiten, alles. Diese Anfragen sind alle an /wp-json/wp-discourse/v1/discourse-comments?post_id=undefined, und ich erhalte etwa 20.000 davon in einem 24-Stunden-Zeitraum (ungefähr entsprechend meiner gesamten Anzahl von ausgelieferten Seiten).
Das wäre mir nicht besonders wichtig, aber die Bearbeitung so vieler zusätzlicher Anfragen belastet meinen WP-Origin-Server spürbar. Es ist im Moment beherrschbar, aber diese Website ist eine Wettervorhersageseite an der Golfküste, und während Wetterereignissen (insbesondere Hurrikans) kann unsere normale tägliche Besucherzahl von 20.000 auf 1,5-2 Millionen ansteigen, und die Bewältigung von Millionen von post_id=undefined-Anfragen an einem Tag wäre eine Herausforderung.
Das Einzige, was ich hier im Meta-Bereich finde, das mit diesem Problem zu tun zu haben scheint, ist dieser Thread aus dem Jahr 2019, wo die gegebene Antwort lautet: „Kommentare mit Ajax laden ausschalten“. Wie oben erwähnt, möchte ich das angesichts der Anforderungen, unter denen ich arbeite, lieber nicht tun.
Hier ist eine repräsentative undefined-Anfrage. Diese wurde generiert, als ich auf die Homepage der Website zugegriffen habe:
Workaround: Da diese Anfragen anscheinend nichts tatsächlich tun, habe ich eine Cloudflare WAF-Regel implementiert, um sie auf CF-Ebene mit einem leeren Antwortkörper zu beantworten. Dies hat die Auswirkungen des problematischen Verhaltens vollständig beseitigt – ich sehe die undefined-Anfragen nicht mehr an meinem Origin und verschwende keine CPU mit der Generierung von Antworten.
Frage: Ist das Senden von discourse-comments?post_id=undefined-Ajax-Anfragen für jede einzelne WP-Seite das beabsichtigte Verhalten des wp-discourse-Plugins? Es scheint, als wäre es vielleicht etwas sicherer (oder zumindest etwas deterministischer), diese Anfragen nur zu senden, wenn tatsächlich ein WP-Beitrag geladen wird (oder auch eine Seite, wenn Seiten in den wp-discourse-Optionen aktiviert sind).
Wie gesagt, ich habe einen Workaround implementiert, der anscheinend funktioniert und die zusätzliche Last der Bearbeitung dieser Zehntausenden von fehlerhaften Anfragen beseitigt, sodass ich stabil und gut aufgestellt bin. Aber es wäre gut zu wissen, ob das von mir beobachtete Verhalten beabsichtigt ist.
