При таких настройках пользовательский опыт был лучше. Да, было несколько «заторов», и в инспекторе Chrome зафиксировано множество ошибок 429. Нагрузка на процессор была низкой. Но, с другой стороны, это была довольно спокойная домашняя игра (многие активные участники находились на месте, но не общались в чате).
Я не могу назвать конкретные параметры, которые нужно изменить, но, исходя из моего довольно субъективного опыта:
Функция кода всё ещё слишком оберегает сервер от нагрузки. Возможно, можно было бы допустить чуть более высокий уровень стресса для сервера.
Когда клиент замедляет запросы, задержка слишком велика с точки зрения UX. Игра продолжается, и за минуту может произойти многое. Чат рассинхронизируется: пользователи ссылаются на разные события игры. (Это усугубляет проблему различных задержек между прямым эфиром, кабельным ТВ, IPTV и буфером Chromecast в 20 секунд и т. д.).
Пользователь видит лишь то, что чат завис, но не получает никаких указаний на то, что сайт всё ещё работает и активен. Скорее всего, он обновит страницу или предпримет другие действия, что лишь увеличивает нагрузку.
Чтобы исключить возможные причины, я обновил сервер до 8 vCores и 32 ГБ ОЗУ. Настроил буферы БД на 16 ГБ и количество процессов Unicorn на 16. Остальные настройки вернул к значениям по умолчанию.
К сожалению, обновление мало что изменило. Быстрые обсуждения постоянно зависают, даже при средней активности.
Производительность в последнее время ужасна. Похоже, мне пора начать изучать Prometheus и подобные инструменты. Я на 95% уверен, что производительность программного обеспечения серьёзно ухудшилась после версии 2.3.
Комментарий брата @Iceman в сентябре в основном был проигнорирован. Он сообщает, что зависания возникают независимо от того, какое оборудование он использует?
Я подозреваю, что вы упираетесь в узкое место Redis, но, как я уже не раз говорил, мы можем быть уверены только в том случае, если вы соберете эти статистические данные. Без них мы можем полагаться лишь на астрологию.
Если мои подозрения верны, это также объяснит, почему добавление более медленных ядер процессора и оперативной памяти не дает никакого эффекта: поскольку Redis работает в одном потоке, масштабирование возможно только за счет использования высокопроизводительных ядер.
Мы выпустим новый образ вместе с финальным релизом версии 2.6 в конце месяца; он будет включать Redis 6 и новые переменные в файле app.yml, которые позволят эффективно использовать эти улучшения. Дайте знать, если хотите протестировать это раньше — я могу предоставить соответствующие инструкции.
Опять же, у нас нет ни одного клиента, который сообщил бы об этом поведении (из тысяч, и многие из них работают гораздо интенсивнее, чем ваш сайт), поэтому дальнейшее обсуждение в данный момент по сути бессмысленно — у нас нет видимости ни в какой странной ситуации с конфигурацией, ни в каких-либо странностях производительности оборудования, которые могут быть у вас.
В будущем, надеемся, это изменится, и у нас появится лучшая видимость реальной проблемы.
Поведение должно заключаться в том, чтобы оставлять их на странице темы и показывать им представление без авторизации, а не перенаправлять на главную страницу.
Так что если Redis является узким местом, как бы вы масштабировались горизонтально?
Меня всё ещё смущает, что изменилось с прошлого сезона. Я не вижу значительного органического роста или увеличения популярности игрового чата. При этом наша способность обслуживать игроков резко снизилась, и система задыхается даже в самых спокойных играх.
Пока вы не сможете собрать метрики с вашего исторического экземпляра Discourse и сравнить их с метриками, собранными на вашей текущей установке, при этом сохранив абсолютно одинаковое оборудование, это останется загадкой.
Вся разница может заключаться в том, что ваш провайдер VPS переместил вас с одной физической машины на другую, или что у вас появился «шумный сосед», или что ваш VPS теперь работает с 17 против 13 в среднем количество совместно размещённых служб на машину.
Пожалуйста, не стоит строить догадки о том, чтобы перекладывать проблему на провайдера VPS. UpCloud — один из лучших на рынке, и они проверили свою сторону на предмет каких-либо аномалий. Они размещают рекламу на нашем сайте, и для нас было бы не очень хорошо с точки зрения PR, если бы сайт начинал «спотыкаться»
Но исторических данных нет, и если честно, я не уделял так много внимания этому вопросу, так как всё работало как часы, пока в августе не начались первые выставочные матчи. Конечно, поведенческие паттерны людей изменились благодаря COVID, и кто знает, что ещё. Хотя я не вижу этого в метриках нашего сайта или сервера.
Но это отличный материал для тестирования. Я только что предоставил @riking скриншоты того, что происходит, когда начинается перегрузка сервера. Думаю, вы сталкиваетесь с этим не так часто.
Обратите внимание, что никто с вами не спорит — мы лишь указываем на то, что врач может сделать не так много для постановки диагноза пациенту, если ограничивается просмотром пациента через веб-камеру в интернете.
Хочу сказать, что я столкнулся с точно таким же поведением, когда впервые настраивал свой сайт (так что это не уникальная проблема именно вашего сайта).
Вот тема, которую я создал по этому поводу в то время:
Именно это заставило меня перейти на другие варианты конфигурации CPU и памяти, описанные здесь:
К сожалению, у меня пока не было возможности полноценно перенести сервер на Hetzner из Digital Ocean, как я планировал (начал новую работу), но сделаю это, как только появится возможность в этом месяце.
Опыт конечного пользователя: его либо выкидывало из темы, либо он оставался в теме (с сообщением о выходе из системы). Это действительно зависело от нагрузки. (Больше пользователей перенаправлялось на главную страницу после гола)
У меня недостаточно технических знаний, чтобы быть полезным, но, возможно, будет полезно знать, что спортивный сайт с похожими пиками активности в чате сталкивается с аналогичной проблемой. В моём случае (меньший и более молодой сайт) проблема была решена дальнейшим улучшением сервера.
Если вы заинтересованы в наличии данных для принятия решений о том, как диагностировать проблемы в будущем, вы можете установить плагин экспортера Prometheus для Discourse.
Установлено новое окружение из 2 контейнеров на 2 VPS-серверах (web_only, data).
Удивительно (для меня), что сервер web_only работает на пределе возможностей, в то время как data нагружен относительно слабо. Оба работают по тарифу UpCloud.com с 4 виртуальными ядрами и 8 ГБ ОЗУ.
Сервер web_only обновлён до тарифа UpCloud.com с 6 виртуальными ядрами и 16 ГБ ОЗУ. Количество процессов Unicorn увеличено до 18.
Тем не менее, мы по-прежнему сталкиваемся с различными лимитерами 429. Однако режим система под высокой нагрузкой не сработал.
Хоккейный сезон был испорчен COVID-ом, и теперь они проводят несколько случайных матчей без зрителей. Поскольку у нас есть кредиты на хостинг в UpCloud.com, мы стараемся улучшить опыт, используя имеющиеся ресурсы. Сейчас работает конфигурация: 6 vCore и 16 ГБ для web_only, а также 4 vCore и 8 ГБ для data, с показателем unicorns на уровне 18.
Мы снова отключили ограничитель скорости запросов…
DISCOURSE_MAX_REQS_PER_IP_MODE: none
…что помогает, но мы всё ещё получаем ошибки 429 от POLL-запросов, что вызывает длительные задержки/зависания для конечного пользователя. Мы продолжим настройку, увеличив значение DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS.
Но прежде чем мы это сделаем, вопрос к @sam / сотрудникам:
В этом не должно быть необходимости. Мы с радостью готовы разместить ваш сайт, чтобы вместе разобраться, почему это ограничение срабатывает у вас постоянно, несмотря на такой низкий трафик.
Возможно, но мы хотели бы быть чуть менее осторожными в отношении сервера, так как естественные всплески активности очень кратковременны и обычно стабилизируются в течение минуты или около того. Поэтому небольшое повышение пороговых значений может улучшить пользовательский опыт, пока мы ждем переезда.
Игр было мало (спасибо COVID), поэтому у нас было очень мало возможностей измерять и экспериментировать с этим.
Мы выяснили, что даже при наших улучшенных аппаратных ресурсах (6+4 vCores и 16+8 ГБ ОЗУ) даже умеренно активная аудитория способна вызывать 429 ошибку «клиент заморожен». Мы наблюдали это во время матчей U20 WC, которые привлекли около ~50% нашей обычной аудитории для чатов.
После измерений, проб и ошибок мы остановились на следующих настройках:
Это, похоже, устраняет 80% ошибок 429, обеспечивая относительно плавный опыт для большинства пользователей.
Следующим шагом могло бы стать приобретение других типов аппаратных ресурсов: либо использование выделенных серверов для однопоточной скорости, либо переход к провайдеру VPS, предлагающему тарифы с огромным количеством vCores. Однако для нас следующим шагом будет работа с командой хостинга Discourse, как намекнул ранее @sam.
Надеемся, эти настройки будут полезны для @iceman, @alec или любого другого пользователя. Обязательно следите за использованием CPU и очередями. Также я узнал из этого опыта, что 2 контейнера намного лучше одного — настройки можно применять с почти нулевым временем простоя, а аппаратные ресурсы используются более гибко.
Меня всё ещё интересуют любые новые настройки или результаты, которые могут помочь улучшить производительность и пользовательский опыт для динамичных обсуждений, вызванных событиями реального мира.
