Прежде всего, я полностью осведомлён о рекомендуемой конфигурации Discourse, но, к сожалению, в данный момент это вне моего контроля.
Теперь о проблеме. У моего клиента есть кастомный фронтенд на React, который использует Discourse в качестве бэкенда. Я унаследовал проект в плачевном состоянии: предыдущие разработчики пытались втиснуть ActionCable в Discourse. Учитывая, что в Discourse для функций реального времени уже используется Message Bus, я подумал, что нам стоит попробовать использовать его.
Локально у нас всё получилось. Message Bus «просто работает»: мы смогли подписаться на все каналы Message Bus по умолчанию в Discourse, а также создать свои собственные.
Проблема возникает в наших удалённых окружениях. Мы разворачиваем приложение на экземплярах AWS EC2, которые находятся за балансировщиком нагрузки ALB, и настраиваем окружение самостоятельно. Мне бы очень хотелось пойти по пути использования Docker, но у клиента просто не было бюджета на то, чтобы потратить время на изменения на этом этапе проекта 
Основной симптом — Message Bus работает ужасно медленно. Ничего не происходит в реальном времени, но мы знаем, что конфигурация Message Bus в порядке, поскольку она отлично работает локально. Значит, проблема в чём-то другом.
Я использую практически стандартную конфигурацию nginx для Discourse. Сначала я думал, что проблема именно в этом, так как в конфигурации nginx для Message Bus чего-то не хватало, но после её добавления это, похоже, не решило наши проблемы.
После просмотра вкладки «Network» в Chrome стало ясно, что проблема есть: наши запросы /poll ждут 25 секунд, а затем скачивают контент за миллисекунды. Я знаю, что должно быть наоборот, как это происходит при локальном запуске или на meta.
Я понимаю, что это может быть также проблемой AWS ALB, но я совершенно не знаю, с чего начать. Не мог бы @sam подсказать, в чём может быть проблема, или направить меня в нужном направлении?
Как всегда, любая помощь будет крайне оценена!