Utilisation du bus de messages dans un client personnalisé sur AWS. Besoin d'un peu d'aide, s'il vous plaît :)

Tout d’abord, je suis parfaitement conscient de la configuration recommandée pour Discourse, mais malheureusement, cela échappe à mon contrôle pour le moment.

Venons-en au problème. Mon client a fait développer un frontend React personnalisé qui utilise Discourse comme application backend. J’ai repris le projet dans un état lamentable, et les développeurs précédents avaient tenté d’intégrer ActionCable dans Discourse. Étant donné que Discourse utilise déjà Message Bus pour les fonctionnalités en temps réel, j’ai pensé que nous devrions probablement essayer de l’utiliser.

Nous avons réussi, localement. Message Bus « fonctionne tout seul » et nous avons pu nous abonner à tous les canaux Message Bus par défaut de Discourse, ainsi que créer nos propres canaux.

Le problème que nous constatons concerne nos environnements distants. Nous déployons sur des instances AWS EC2 situées derrière un ALB et nous construisons l’environnement nous-mêmes. J’aurais adoré opter pour la solution Docker, mais le client n’avait simplement pas le budget pour consacrer du temps à modifier les choses à ce stade du projet :sadpanda:

Le symptôme principal est que Message Bus rame terriblement. Rien n’est vraiment en temps réel, mais nous savons que la configuration de Message Bus est correcte car elle fonctionne parfaitement en local, donc il doit s’agir de quelque chose d’autre.

J’utilise pratiquement la configuration nginx par défaut de Discourse. J’ai d’abord pensé que c’était le problème, car la configuration nginx pour Message Bus manquait, mais après l’avoir ajoutée, cela ne semble pas avoir résolu les problèmes que nous constatons.

Après avoir examiné l’onglet Réseau dans Chrome, il est clair qu’il y a un problème car nos requêtes /poll attendent pendant 25 secondes avant de télécharger du contenu en quelques millisecondes. Je sais que cela devrait être l’inverse, comme lorsque je l’exécute localement ou comme sur meta.

Je suis conscient que cela pourrait aussi être un problème lié à AWS ALB, mais je suis littéralement sans idée de où commencer. Je me demandais si @sam aurait une idée de ce qui pourrait poser problème, ou pourrait m’orienter dans la bonne direction.

Comme toujours, toute aide, quelle qu’elle soit, est très appréciée !

Nous utilisons un bus de messages avec des ALB ; en fait, Meta est hébergé sur AWS.

Je suppose qu’ailleurs dans votre pile, le tamponnage des requêtes est activé, ce qui les maintient pendant de longues périodes.

Il s’agit très probablement de proxy_buffering dans NGINX, qui est défini sur on au lieu de off.

Salut @sam,

Merci pour cette suggestion. Cela semble avoir résolu le problème dans le volet réseau : le contenu téléchargé est maintenant affiché comme 25 s et l’attente comme 35 ms une fois la requête terminée.

Cependant, j’avais cru comprendre qu’un message serait traité dès sa réception. Notre application semble toujours attendre la fin du sondage avant de traiter les messages reçus.

Nous avons activé le long polling et l’encodage par morceaux, et comme mentionné, nous utilisons Discourse comme backend, nous supposons donc qu’aucune configuration supplémentaire n’est nécessaire de ce côté.

Des idées ? Merci.