Обновление тем в реальном времени зависает при высокой активности

Поддержка
1

Примечание: Я не уверен, является ли это ошибкой в Discourse. Я попытался собрать необходимые доказательства, и пока ничего, указывающего на проблемы с нашей инфраструктурой или настройкой, не обнаружено. Наша конфигурация на Tappara.co максимально близка к стандартной.

Наблюдаемое явление:

  • Темы чата с быстрым обсуждением перестают обновляться автоматически. После задержки от 30 до 180 секунд обновление обычно возобновляется, показывая сообщения, отправленные во время «заморозки».

Что нам известно на данный момент

  • В прошлом сезоне, когда последний матч проходил в марте, такой проблемы не наблюдалось.
  • Мы используем стабильную ветку, последнее крупное обновление было установлено в августе.
  • Проблема была немедленно сообщена во время первых выставочных игр при умеренном трафике и активности.
  • Это влияет на Chrome для iOS и Android, но встречается гораздо реже на Chromebook.
    • В момент написания этого сообщения я наблюдаю «заморозки» на своём Android-телефоне, тогда как на Chromebook обсуждение идёт как положено. Два разных устройства в одной сети.
  • Опыт варьируется в зависимости от пользователя/клиента. Разные пользователи сообщают о «заморозках» в разное время. В целом за 30 минут было зафиксировано около 300 сообщений, а пользователи сообщили о десятках «заморожек». Чаще всего «заморозки» коррелируют с событиями в игре (голы, штрафы).

Что я пытался исключить

  • CloudFlare — мы провели один матч без кэширования через CF, и проблема сохранилась.
  • Перегрузка CPU — использование процессора находится в пределах нормы, обычно колеблется вокруг 20–30%.
  • Истощение дискового пространства — ввод-вывод диска также в пределах нормы. У нас SSD от UpCloud с максимальной производительностью IOPS.

Дополнительная информация

  • Во время матча у меня был запущен инспектор Chrome, и было зафиксировано несколько ошибок 429, но для меня они не коррелировали с «заморозками».
  • Конечные пользователи не получают уведомлений об ошибках 429 (замедление) или экстремальной нагрузке. Обновление просто «зависает», а затем возобновляется. Не изменился ли недавно лимитер запросов? У меня сложилось впечатление, что лимиты должны вызывать уведомление в интерфейсе?

Это действительно серьёзная проблема, которая сильно мешает чатам с комментариями в реальном времени во время игр. Мы проводим такие трансляции уже несколько лет, и я никогда раньше такого не видел.

2

Что ж, это не баг, а фича :sweat_smile:.

Когда ваши веб-воркеры начинают перегружаться запросами, мы вводим задержки в постоянном соединении, которое автоматически обновляет тему при появлении новых постов.

Если вы видите это сообщение и при этом наблюдается низкая загрузка ЦП, как указано, пожалуйста, увеличьте количество воркеров Unicorn — это должно решить проблему.

3

Уже 11 «Единорогов» на VPS с 6 ядрами. Как уже говорилось, в прошлый сезон, вплоть до марта, такого не было. Сейчас проблема возникает даже при умеренном трафике. Кроме того, на мобильных устройствах, особенно в Chrome на Android, это происходит гораздо чаще, чем на настольных компьютерах.

Ранее нам также удавалось исчерпать ресурсы CPU (например, в дедлайн по трансферам).

Я пропустил игру, пока мониторил и настраивал сервер. Мы удвоили параметры web.ratelimited, но это не решило проблему.

Inspector фиксирует множество ошибок 429:

1. URL запроса:

https://tappara.co/message-bus/3ed86765a67f4c31ba4053a0352ecaf5/poll

2. Метод запроса:

POST

3. Код состояния:

429

Завтра следующая игра, так что я смогу попробовать «Единорогов». Насколько высоко мы можем зайти? Изменилось ли что-то с последним крупным обновлением?

Редактирование:

Я посмотрел статистику, и наша активность пока что ниже, чем была весной (просмотры страниц, пользователи). Количество постов в чате игры такое же (около 900–1000 за 3 часа).

Таким образом, по неизвестной причине мы сейчас не можем обслуживать ту же аудиторию, что и в марте.

4

Я работаю над анализом этой проблемы в течение следующих двух недель, на её решение потребуется время.

5

Отлично! Не могли бы вы подтвердить, произошло ли недавно (в течение последних 6 месяцев) изменение или регрессия, вызвавшая это?

Тем временем я, пожалуй, увеличу количество единорогов на сегодняшней игре и посмотрю, что получится. Если мы сможем чем-то помочь, просто дайте знать.

6

@falco Количество единорогов точно не является ключевым фактором. Я увеличил их до 15 для сегодняшней игры. Тема игры была спокойной, всего 700 сообщений, но наблюдались постоянные зависания. Нагрузка на процессор была умеренной, в диапазоне 5–25%.

Чем больше я исследую это, тем более вероятным кажется, что это ошибка и регрессия, но моих навыков недостаточно, чтобы определить, где именно.

7

По-видимому, в клиенте есть ошибка, из-за которой он прекращает обновление после получения одной ошибки. Я подозреваю, что вы столкнулись с этим, потому что ваши пользователи попадают под ограничение частоты запросов (rate limit).

На этой неделе я займусь изучением вопроса повышения устойчивости клиента, как я уже упоминал ранее: это капризный код, и работа займёт время.

8

Отлично. Тем временем я проверю, будет ли отключение глобального лимитера рабочим решением. Мы узнаем это в среду.

9

Отладка этой проблемы заставила меня задуматься о UX дискуссий в режиме, близком к реальному времени, в целом. Многие сообщества сталкиваются с событиями из реальной жизни, которые естественным образом «подталкивают» обсуждение к быстрому, чат-подобному формату. Это может быть фондовый рынок, крупное событие запуска продукта или игра (киберспорт или физическая)… что угодно.

Однако в такой чат-подобной культуре качество постов сильно варьируется. С другой стороны, посты имеют естественную тенденцию появляться именно в одно и то же время. Давайте представим, что идет большой хоккейный матч, и кто-то забивает гол.

  • Значительная часть постов — это просто эмоциональные реакции, возгласы радости или сожаления.
    • «Гол!!! Да, детка!»
  • Некоторые носят информационный характер:
    • «Кросби забивает, 1:0 в пользу «Пенс»»
  • Небольшое меньшинство прилагает усилия для анализа:
    • «Кросби забивает гол в большинстве после неосторожного давления «Кэпс», но это выглядело очень похоже на офсайд. Тренер «Кэпс» должен оспорить это.»

Теперь, учитывая, что Discourse — это быстрая платформа (почти в реальном времени), это означает, что даже при безупречной работе вы получите несколько десятков постов практически в один и тот же момент. Для читателя, особенно того, кто не смотрит игру, но следит за ней в теме чата, это создает проблему UX — трудно заметить информативные посты среди возгласов радости и сожаления. На наших игровых чатах форума часто задают вопрос «Какой счёт?», так как зрители игры забывают написать очевидное, или информация теряется в потоке сообщений.

Я не знаю, как это работало бы в реальной жизни, но было бы интересно протестировать возможность настройки администраторами темпа обсуждения. Например, один пост в секунду. Все посты будут ставиться в очередь, но публиковаться на сайте с заданным темпом. Если гол порождает 20 постов с реакциями, они не появятся в теме одновременно, а будут распределены в течение 20 секунд. Не будет ли так легче следить за ходом событий и улавливать важную информацию?

Это, конечно, может привести к другим проблемам: если темп поступления новых сообщений постоянно будет превышать темп их публикации, очередь будет расти, и чат начнет отставать от реальности.

Не уверен, что вы уловили суть, и даже сам не уверен, хороша ли эта идея. Главное в том, что UX чатов в реальном времени — это интересная тема для обсуждения и, возможно, имеет потенциал для дальнейшей разработки? Я понимаю, что основной фокус Discourse — не создание чат-платформы, для этого есть другое ПО. Но такие ситуации возникают естественно.

10

Мне нравится эта идея, но потребуется某种形式的 обратного теневой блокировки, чтобы пользователи всегда видели свои собственные сообщения сразу. Если этого не произойдет, они могут начать дублировать или даже многократно публиковать одно и то же, полагая, что форум не работает.

11

Я только что объединил это:

https://review.discourse.org/t/perf-backoff-background-requests-when-overloaded-10888/16227

Это гарантирует, что сервер не будет отключён, если 1000 человек просматривают одну тему и публикуются новые сообщения.

Теперь клиент ведёт себя гораздо стабильнее в таких случаях.

Отвечая на вопрос @ljpp, я ещё не решил, стоит ли делать бэкпорт: это вносит изменения в API и является довольно масштабным изменением. Если мы всё же сделаем бэкпорт, это, вероятно, произойдёт через несколько недель. Мне нужно наблюдать за этим в продакшн-окружении под нагрузкой, но подобных событий у нас случается крайне редко, так как у наших хостинг-ресурсов есть большой запас прочности, поэтому нам потребуется время, чтобы зафиксировать такой случай.

12

Трюки джедаев :wink:

  • Мы попробуем проверить, является ли отключение ограничителя частоты запросов жизнеспособным обходным решением.
  • Если да: следующее стабильное издание, полагаю, уже не за горами.
  • Если нет, мы обратим внимание на бета-канал. Нам нужно будет убедиться, что наша настройка интерфейса не сломается при обновлении.

Есть ли у нас другие сообщества с похожими чат-подобными обсуждениями, работающие на ветках edge?

13

Ожидайте его к концу года… поэтому я бы не ждал его в самое ближайшее время. Однако на этой неделе мы выпустим ещё одну бета-версию!

Все наши хостинги работают на бета-версии… так что да, но у нас огромный запас мощности.

14

Я понимаю логику, по которой это может не подойти для бэкпорта. Я только что отключил наш ratelimiter, и завтра следующая игра, так что у нас будет довольно четкое представление о том, является ли это жизнеспособным обходным решением для инстансов, не желающих переходить на бета-версию.

Мы определенно рассматриваем возможность перехода на бета-ветку на ближайшие несколько месяцев. Однако есть и другие опасения — @rizka указал, что перевод на финский язык отстает (но он, возможно, сможет поработать над этим позже на этой неделе).

16

@sam

К сожалению, отключение ограничителя скорости совсем не помогло. Игра была скучной: 83 пользователя отправили всего 580 сообщений. В ходе игры сообщалось о нескольких зависаниях.

Есть ли какие-либо потенциальные взломы или обходные пути, которые можно попробовать, пока мы ждём обновления до edge-версии?

17

«Заморозки» — это ошибка клиента, который просто некорректно реагировал на условия ошибок. Достаточно одной ошибки ограничения частоты запросов, и стабильная версия перестанет работать.

Я не могу придумать обходной путь, кроме как обновиться до бета-версии (мы выпускаем новую уже завтра).

18

Один из наших участников, ориентированных на разработку, предложил изменить следующую переменную. Что вы думаете — видите ли вы в этом потенциальное решение?

DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.2

19

Мы опробовали этот хак:

DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.2

Это значительно сократило количество наблюдаемых замедлений, но не решило проблему. Нагрузка на процессор возросла и колебалась около 55% во время крупных событий в игре.

20

Недавно были внесены изменения для решения проблемы с «зависаниями»: если сервер перегружен, клиент будет делать паузу и ждать.

В конечном итоге, возможно, потребуется перейти на более мощный сервер и запустить больше воркеров Unicorn. См. скрипт discourse-setup для наших рекомендаций по соотношению мощности сервера и количества воркеров.

21

Сомневаюсь… Проблема при высокой нагрузке на ответы заключается в том, что до нового дизайна мы могли вызывать флуд, который приводил бы к срабатыванию лимитов частоты запросов из-за параметров вроде max_reqs_per_ip_per_10_seconds. Для обработки такой нагрузки требовались бы огромные ресурсы.

Подумайте:

  • 30 пользователей публикуют ответ в течение 10 секунд.
  • 100 человек просматривают тему.
  • Сервер должен быть способен обработать 3000 GET-запросов для получения одного сообщения за раз.
  • Если ЛЮБОЙ из этих запросов завершится ошибкой по любой причине, интерфейс зависнет и будет выглядеть сломанным.

Новый дизайн очень чисто решает эту проблему: нагрузка плавно снижается, запросы объединяются в пакеты при возникновении очереди, интерфейс не зависает и так далее.

Я не вижу возможности масштабирования старого дизайна до 100 одновременных пользователей и 30 ответов за 10 секунд.

Я вижу, что текущий переработанный дизайн отлично справится с 1000 одновременными пользователями, просматривающими тему с 30 ответами за 10 секунд.