Environnement : Discourse auto-hébergé sur AWS EC2, avec l’AMI Ubuntu 24.04. L’hôte est un r7g.large avec 2 vCPU et 16 Go de RAM. Discourse est à la version 3.6.0.beta1-dev (db974047e4) et est mis à jour régulièrement. WordPress est à la version 6.8.2, et le plugin wp-discourse est à la version 2.5.9. WordPress et Discourse sont tous deux proxysés (“nuage orange”) derrière Cloudflare.
Paramètres actuels de wp-discourse : J’affiche les commentaires Discourse pour tous les sujets, et j’ai activé “Charger les commentaires avec Ajax”. (Les lecteurs et les propriétaires du site WordPress souhaitent que les nouveaux commentaires soient affichés le plus rapidement possible sous les articles WP, donc selon les exigences des propriétaires, je préférerais laisser “Charger les commentaires avec Ajax” activé.)
Ce que je constate : En général, wp-discourse fonctionne très bien. Lorsqu’un lecteur visite un article WP, son navigateur demande /wp-json/wp-discourse/v1/discourse-comments?post_id=XXXXX, où XXXXX est l’ID de l’article attendu, et les commentaires se chargent sans problème. Les nouveaux commentaires apparaissent sur le côté WordPress quelques secondes après avoir été publiés sur Discourse.
Cependant, les navigateurs des visiteurs émettent également un appel à la même URI discourse-comments lorsqu’ils visitent n’importe quelle adresse WordPress sur l’ensemble du site. La page d’accueil du site, les archives de commentaires, la page “À propos”, la page de contact, les pages de biographie d’auteur, les pages statiques, les pages de recherche, tout. Ces requêtes sont toutes pour /wp-json/wp-discourse/v1/discourse-comments?post_id=undefined, et j’en reçois environ 20 000 par période de 24 heures (correspondant approximativement à mon nombre total de pages servies).
Cela ne me dérangerait pas beaucoup, sauf que le traitement d’un si grand nombre de requêtes supplémentaires crée une charge notable sur mon serveur d’origine WP. C’est gérable maintenant, mais ce site est un site de prévisions météorologiques de la côte du Golfe et, lors d’événements météorologiques (en particulier les ouragans), notre nombre de vues quotidiennes peut passer de ses 20 000 habituels à entre 1,5 et 2 millions, et gérer des millions de requêtes post_id=undefined par jour serait difficile.
La seule chose que j’ai trouvée ici sur meta qui semble avoir un rapport avec ce problème est ce fil de discussion de 2019, où la réponse donnée est “désactiver le chargement des commentaires avec ajax”. Comme mentionné ci-dessus, compte tenu des exigences auxquelles je suis soumis, je préférerais ne pas le faire.
Voici une requête undefined représentative. Celle-ci a été générée lorsque j’ai accédé à la page d’accueil du site :
Solution de contournement : Puisque ces requêtes ne semblent pas faire quoi que ce soit, j’ai implémenté une règle WAF Cloudflare pour y répondre au niveau de CF avec un corps de réponse vide. Cela a complètement éliminé les effets du comportement problématique : je ne vois plus les requêtes undefined sur mon origine, et je ne gaspille pas de CPU à générer des réponses.
Question : L’envoi de requêtes ajax discourse-comments?post_id=undefined pour chaque page WP est-il le comportement prévu du plugin wp-discourse ? Il semble que ce serait un peu plus sûr (ou du moins un peu plus déterministe) de n’envoyer ces requêtes que lors du chargement réel d’un article WP (ou d’une page, également, si les pages sont activées dans les options de wp-discourse).
Comme je l’ai dit, j’ai une solution de contournement en place qui semble faire l’affaire et supprimer la charge supplémentaire de traitement de ces dizaines de milliers de requêtes parasites, donc je suis stable et dans une bonne situation. Mais ce serait bien de savoir si le comportement que je constate est intentionnel.
