Message Bus in einem benutzerdefinierten Client auf AWS verwenden. Bitte um etwas Hilfe :)

Zunächst einmal: Ich bin mir der empfohlenen Discourse-Setup-Konfiguration bewusst, aber leider liegt dies derzeit nicht in meiner Macht.

Kommen wir nun zum Problem. Mein Kunde hatte ein benutzerdefiniertes React-Frontend entwickelt, das Discourse als Backend-Anwendung nutzt. Ich habe das Projekt in einem schlechten Zustand übernommen, und die vorherigen Entwickler hatten versucht, ActionCable in Discourse hineinzupressen. Da Discourse bereits Message Bus für Echtzeitfunktionen verwendet, dachte ich, wir sollten versuchen, diesen ebenfalls zu nutzen.

Lokal war das erfolgreich. Message Bus „funktioniert einfach“, und wir konnten uns sowohl für alle standardmäßigen Discourse Message Bus-Kanäle abonnieren als auch einige eigene erstellen.

Das Problem, das wir beobachten, tritt in unseren Remote-Umgebungen auf. Wir deployen auf AWS EC2-Instanzen, die hinter einem ALB liegen, und haben die Umgebung selbst aufgebaut. Ich hätte gerne den Docker-Weg gewählt, aber der Kunde hatte einfach kein Budget, um in diesem Projektstadium Änderungen vorzunehmen :sadpanda:

Das Hauptsymptom ist, dass Message Bus schrecklich verzögert reagiert. Nichts ist wirklich echtzeitfähig, aber wir wissen, dass die Message-Bus-Konfiguration in Ordnung ist, da sie lokal hervorragend funktioniert. Also muss etwas anderes das Problem sein.

Ich verwende praktisch auch die Standard-Discourse-nginx-Konfiguration. Anfangs dachte ich, das sei das Problem, da die Message-Bus-nginx-Konfiguration fehlte. Doch nachdem ich sie hinzugefügt habe, scheint das die von uns beobachteten Probleme nicht gelöst zu haben.

Nachdem ich im Chrome-Tab „Netzwerk“ nachgesehen habe, ist klar, dass ein Problem besteht: Unsere /poll-Anfragen warten 25 Sekunden lang, bevor sie Inhalte in Millisekunden herunterladen. Ich weiß, dass es umgekehrt sein sollte, wie bei meinem lokalen Lauf oder wie auf meta.

Mir ist bewusst, dass dies auch ein Problem mit dem AWS ALB sein könnte, aber ich habe buchstäblich keine Ahnung, wo ich anfangen soll. Ich habe mich gefragt, ob @sam vielleicht eine Idee hat, woran das liegen könnte, oder mich in die richtige Richtung lenken kann.

Wie immer ist jede und jede Hilfe sehr willkommen!

Wir haben einen Message Bus, der mit ALBs funktioniert; tatsächlich ist Meta auf AWS gehostet.

Meine Vermutung ist, dass irgendwo in Ihrem Stack die Pufferung von Anfragen aktiviert ist, was dazu führt, dass diese über längere Zeiträume zurückgehalten werden.

Am wahrscheinlichsten ist, dass proxy_buffering in NGINX auf on statt auf off gesetzt ist.

Hallo @sam,

danke für diesen Vorschlag. Es scheint, als hätte er das Problem im Netzwerk-Pane behoben, d. h. es wird nun angezeigt, dass der Inhalt nach 25 Sekunden heruntergeladen wurde und nach Abschluss der Anfrage 35 ms Wartezeit benötigt.

Ich war jedoch der Meinung, dass eine Nachricht sofort bearbeitet wird, sobald sie empfangen wurde. Unsere App scheint weiterhin darauf zu warten, dass die Abfrage abgeschlossen ist, bevor sie empfangene Nachrichten verarbeitet.

Wir haben Long Polling und Chunked Encoding aktiviert, und wie erwähnt nutzen wir Discourse als Backend, weshalb wir davon ausgehen, dass dort keine weiteren Konfigurationen erforderlich sind.

Habt ihr Ideen? Danke.