Ambiente: Discourse self-hosted su AWS EC2, con l’AMI Ubuntu 24.04. L’host è un r7g.large con 2 vCPU e 16 GB di RAM. Discourse è alla versione 3.6.0.beta1-dev (db974047e4) e viene aggiornato regolarmente. WordPress è alla versione 6.8.2 e il plugin wp-discourse è alla versione 2.5.9. Sia WordPress che Discourse sono proxati (“nuvola arancione”) dietro Cloudflare.
Impostazioni wp-discourse correnti: Sto visualizzando i commenti di Discourse per tutti gli argomenti e ho selezionato “Carica commenti con Ajax”. (Sia i lettori che i proprietari del sito WordPress desiderano che i nuovi commenti vengano visualizzati il prima possibile sotto i post di WP, quindi in base ai requisiti dei proprietari, preferirei lasciare abilitato “Carica commenti con Ajax”.)
Cosa sto vedendo: In generale, wp-discourse funziona benissimo. Quando un lettore visita un post di WP, il suo browser richiede /wp-json/wp-discourse/v1/discourse-comments?post_id=XXXXX, dove XXXXX è l’ID del post previsto, e i commenti vengono caricati senza problemi. I nuovi commenti appaiono sul lato WordPress entro pochi secondi dalla pubblicazione su Discourse.
Tuttavia, i browser dei visitatori emettono anche una chiamata allo stesso URI discourse-comments quando visitano qualsiasi indirizzo WordPress dell’intero sito. La homepage del sito, gli archivi dei commenti, la pagina “chi siamo”, la pagina dei contatti, le pagine della biografia dell’autore, le pagine statiche, le pagine di ricerca, tutto. Queste richieste sono tutte per /wp-json/wp-discourse/v1/discourse-comments?post_id=undefined, e ne ricevo circa 20.000 in un periodo di 24 ore (corrispondenti approssimativamente al numero totale di pagine servite).
Non mi importerebbe molto, se non fosse che la gestione di così tante richieste aggiuntive sta creando un carico notevole sul mio server di origine WP. Al momento è gestibile, ma questo sito è un sito di previsioni meteorologiche della costa del Golfo e durante gli eventi meteorologici (soprattutto uragani) il nostro conteggio giornaliero delle visualizzazioni può aumentare dalle normali 20.000 a 1,5-2 milioni, e gestire milioni di richieste post_id=undefined in un giorno sarebbe impegnativo.
L’unica cosa che ho trovato qui su meta che sembra avere a che fare con questo problema è questa discussione del 2019, dove la risposta data è “disattivare il caricamento dei commenti con ajax”. Come notato sopra, date le esigenze in base alle quali sto operando, preferirei non farlo.
Ecco una richiesta rappresentativa di undefined. Questa è stata generata quando ho visitato la homepage del sito:
Soluzione temporanea: Poiché queste richieste non sembrano fare nulla, ho implementato una regola WAF di Cloudflare per rispondere loro a livello di CF con un corpo di risposta vuoto. Questo ha completamente eliminato gli effetti del comportamento problematico: non vedo più le richieste undefined sulla mia origine e non spreco CPU generando risposte.
Domanda: L’invio di richieste ajax discourse-comments?post_id=undefined per ogni singola pagina WP è il comportamento previsto del plugin wp-discourse? Sembrerebbe un po’ più sicuro (o almeno un po’ più deterministico) inviare tali richieste solo quando si carica effettivamente un post WP (o anche una pagina, se le pagine sono abilitate nelle opzioni di wp-discourse).
Come ho detto, ho una soluzione temporanea in atto che sembra funzionare e rimuovere il carico aggiuntivo della gestione di decine di migliaia di richieste spurie, quindi sono stabile e in una buona posizione. Ma sarebbe bello sapere se il comportamento che sto riscontrando è intenzionale.
