Спасибо. Вы, скорее всего, сэкономили мне много часов отладки и перебора вариантов.
Это различие в поведении привело меня к выводу, что здесь имеет место какая-то прикладная корреляция, вытекающая из проблемы на стороне фронтенда, которая «крашит» приложение (поскольку фронтенд — не моя сфера экспертизы, в отличие от бэкенда), в сочетании с операциями по публикации и тем, что пользователи остаются в теме, ожидая её «самообновления» с десятками сообщений за одну минуту.
Если подытожить это многословное предложение: ваш вывод заключается в том, что «задушение» быстрой дискуссии в реальном времени — это проблема на стороне фронтенда?
Мне не удалось продвинуться далеко в нашем анализе, но я заметил, что нагрузка на процессор была далеко не максимальной, всего около 25%. За многие годы мы не раз достигали 100% нагрузки на CPU, но в последнем инциденте в прошлую субботу такого не было. У нас было всего около 150 одновременных пользователей.
То, что заставило меня заподозрить бэкенд, — это факт, что мы уже много лет проводим эти игровые чаты, и я никогда раньше не сталкивался с таким «задушением». За эти годы база данных выросла, и теперь у нас более 800 000 сообщений.
Когда вы впервые заметили это? Может ли это быть регрессией из-за последнего крупного обновления? Наш сайт и его производительность были в порядке весной, и за лето мы не выросли настолько значительно.
Babel — это исключительно неэффективный плагин, поэтому, если вы используете Babel, у вас возникнут проблемы, особенно при высокой нагрузке с большим количеством одновременно активных пользователей.
Теперь в нашем бэклоге есть задача по улучшению производительности в случаях, когда 1000 человек просматривают одну и ту же тему, и один человек публикует сообщение.
Как это реализовано сегодня, мы рассылает всем 1000 пользователям уведомление: «Привет, в этой теме появилось новое сообщение», после чего все 1000 человек одновременно обращаются к серверу с вопросом: «Эй, что это за новая тема, о которой вы говорите?»
Мы планируем рассмотреть возможность минимального и более аккуратного ограничения частоты запросов, чтобы клиенты не перегружали сервер, но для этого редкого случая существует множество других возможностей для оптимизации.
Отличные новости, что это у вас на контроле. Можете подтвердить, не возникло ли регрессии с прошлой весны?
Наша местная хоккейная лига пытается начать игры 1 октября. Это означает, что наш сайт может генерировать реальные всплески трафика на еженедельной основе, на случай если вам нужно/хочется изучить поведение в реальной (несимулированной) среде.
Напишите в личные сообщения, если заинтересованы. Мы с радостью поддержим.
С точки зрения UX, конечный пользователь каким-то образом должен понимать, что обсуждение активно, даже когда система начинает работать со сбоями. Это может предотвратить ненужные обновления страницы в браузере.
Первая игра только что завершилась, и у нас определённо возникла проблема, которой не было в марте. Причина пока неизвестна.
Чат игры зависает на фронтенде, хотя нагрузка на сервер должна быть значительно ниже 100%.
Один из наших пользователей заметил множество ответов сервера 429 во время зависаний, но я не могу сказать, является ли это «нормальным», так как мы ранее не проводили подобных проверок во время игр.
Я видел один из них, когда исследовал совершенно не связанный с этим ‘500’
Сервер совсем не был занят, но я возился с конфигурацией фронтенд-nginx (http2).
Действительно. За пару часов было около 900 реакционных ответов. @ljpp располагает более точными данными по количеству пользователей, но речь идёт о сотнях людей, просматривающих тему в любой момент во время матча.
Странно, но это влияет не на всех пользователей. Я, например, не столкнулся с какими-либо проблемами ни на одном устройстве. Однако, судя по сообщениям, проблема носит массовый характер.
Это не так очевидно заметить, особенно если не обращать пристального внимания.
Сначала происходит задержка на 30–60 секунд без ответов. Ничего не кажется «неправильным», просто тихо. Вы даже можете написать свой собственный пост. Затем внезапно вы получаете десятки сообщений за мгновение и понимаете, что отстали. Я наблюдал это в Safari на iOS и Chrome на Android.
Наши чаты для реального времени в играх загружены, но не в экстремальных случаях. Вчера за ~3 часа было отправлено 972 сообщения.
Следующий игровой чат состоится сегодня в 14:00 UTC. Из-за пандемии я ожидаю схожие показатели, даже хотя это домашний матч.
Разве вы не пытаетесь навязать сценарий использования чата на платформе форума?
Почему бы вам вместо этого не интегрировать сервис чата, такой как Mattermost или Discord, в интерфейс вашего сайта на Discourse, а этот формат оставить для обсуждения внутри игры?
Вы могли бы найти другой способ освещать игру в теме форума, например, обсуждение до или после матча, где нагрузка на систему может быть менее интенсивной, но при этом содержать полезную сводную информацию, которую многие пользователи, возможно, захотят найти позже.
Я также не вижу преимуществ в хранении огромного объема спонтанных сообщений чата на форуме. Разве кто-то будет это перечитывать? Это полезно?
Что ж, он называет это «чатом», но, по словам пользователя, его настройка Discourse не справляется с «972 сообщениями за ~3 часа» в одной теме. На мой взгляд, должна справляться: даже простой phpBB может обработать за 3 часа в несколько раз больше.
То есть 1 пост каждые 10 секунд? Само по себе это звучит не так уж нереально. Но если вы делаете тему длиной в 1000 постов, в которой участвуют несколько сотен пользователей, и к этому добавляются всплески активности, я вижу, в чём сложность!
Но в чём же на самом деле кроется проблема или узкое место? В количестве участников, в ограничении одного поста каждые 10 секунд, в рендеринге изменённого контента для (слишком) большого числа анонимных или неанонимных пользователей, или в количестве соединений, необходимых для обслуживания множества авторизованных пользователей?
Появится ли у него та же проблема, если всего два пользователя будут создавать такое же количество постов в теме в тот же промежуток времени?
Даже если всего 972 авторизованных пользователя сделают по одному посту в этой теме, не справится ли Discourse с этим? И если нет, то почему? Подходит ли Discourse только для очень небольших сообществ с малым количеством одновременных авторизованных пользователей?
Меня это интересует, поскольку у нас уже бывает до 400 одновременных авторизованных пользователей, которые создают до 3000 постов в день… пока никаких проблем не возникало.
Очевидно, необходимо учитывать характеристики сервера и количество запущенных юнитов, иначе результаты тестов на нагрузочное тестирование будут менее значимыми.
Blenderartists (@bartv), насколько я знаю, имеют сервер с 64 ГБ ОЗУ и около десятка запущенных юнитов? Это настоящий монстр
Абсолютно, сейчас у нас всего 8 ГБ ОЗУ и 4 vCPU у DigitalOcean, и проблем пока нет. Так что, если решение этой проблемы — просто добавить ресурсов (ОЗУ и CPU), меня это устраивает. С момента перезапуска с Discourse был пик: около 2000 одновременных посетителей на одном вирусном посте, нагрузка чуть выше 1, загрузка CPU составляла 60–70%. В среднем при примерно 200–250 одновременных авторизованных пользователей загрузка CPU сейчас составляет около 15–20%.
Можно так утверждать, но мне очень не нравится идея разделения разговоров между двумя платформами. Реальное время — это на самом деле одна из ключевых особенностей Discourse, которую ценят конечные пользователи. Наши игровые обсуждения пользуются большим успехом и являются важной частью культуры сообщества.
Обратите внимание, что мы проводим их уже четыре года, и это новая проблема, с которой мы столкнулись. Таким образом, сотни игр прошли успешно, без какого-либо «навязывания».
Один из наших опытных участников выдвинул гипотезу — возможно, мы достигаем глобальных лимитов Discourse, и, возможно, на это влияет CloudFlare.
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE : количество запросов с одного IP-адреса в минуту (по умолчанию 200)
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS : количество запросов с одного IP-адреса за 10 секунд (по умолчанию 50)
Следующая игра начнется через час, и мы попробуем отключить кэширование CloudFlare.
Обратите внимание, что мы используем CloudFlare уже 4 года, хотя здесь это обычно не рекомендуется. За это время возникла лишь одна-две проблемы: поддержка Brotli и устаревший шаблон.
