“Из-за экстремальной нагрузки это временно отображается для всех так, как это видит пользователь без авторизации”
Я управляю сайтом с живыми трансляциями обсуждений во время баскетбольных матчей и сталкиваюсь с проблемами перегрузки сервера, из-за чего во время игр (пиковая активность) появляется это сообщение.
Есть ли способ определить лучший подход к решению этой проблемы? Проблема в скорости хранения данных, оперативной памяти или процессоре? Есть ли что-то, что можно сделать помимо модернизации сервера? Или, если я всё же буду её улучшать в такие моменты, на что именно стоит обратить внимание?
Меньше людей используют форум? Ещё лучше было бы, если бы они распределяли своё использование, а не делали всё во время игры.
Но ничего из этого не поможет. Поскольку вы знаете, когда проходят игры, вы могли бы усиливать свой сервер только во время игры или запускать несколько серверов во время игры за балансировщиком нагрузки.
Вам потребуется больше и более быстрых ядер процессора, а также больше оперативной памяти, чтобы увеличить количество веб-процессов (Unicorn Workers) и справляться с пиковыми нагрузками.
Это область, над которой @sam активно работает. Похоже, что в новых версиях Discourse в этом аспекте произошёл регресс с точки зрения производительности.
Тем не менее, настоящее решение — использовать инструмент для живого чата, если вам нужны живые взаимодействия в реальном времени для сотен людей одновременно, хотя я продолжаю сомневаться, как и почему чат бывает «полезным», когда он прокручивается так быстро, что никто не может ничего увидеть, как в стримах Twitch и YouTube.
Вот мой опыт работы с футбольным форумом во время матчей до возникновения проблем:
Digital Ocean
1 CPU, 1 ГБ = 30–40 пользователей в режиме чата
2 CPU, 2 ГБ = 70–80 пользователей в режиме чата
4 CPU, 8 ГБ = стабильно работает для 120 пользователей и 1000 постов за 2 часа. Лимит не был достигнут.
С Hetzner (зеркальный сайт)
Мой опыт:
3 CPU (CPX 21, чип AMD) и 4 ГБ = проблемы уже при 20 пользователях
2 CPU (Intel) и 8 ГБ = проблем с 20 пользователями нет.
Мне так и не удалось протестировать с большим количеством пользователей.
Главное — увеличить мощность CPU и объём оперативной памяти. А ТАКЖЕ отредактировать файл app.yml.
Добавьте больше юниконов здесь, а также измените параметр db_shared_buffers.
Для спортивных форумов это ближе к живым текстовым обновлениям матчей. Люди не столько общаются в чате (хотя это происходит в какой-то степени, особенно в перерывах), сколько получают живые текстовые комментарии от других болельщиков.
Многие заходят на форум просто чтобы прочитать текстовую трансляцию. Видя мысли и мнения ключевых участников о важных моментах матча — от забавных реакций до серьёзного анализа.
Если вы пропустили игру, люди заходят, чтобы просто прочитать поочерёдное описание событий. Это отлично подходит для тех, кто на работе Это более лично и предвзято, чем текстовые комментарии в газетах или на телеканалах.
Я вас понимаю, мы с @sam и @eviltrout внимательно изучаем этот вопрос.. ситуация, когда «сотни пользователей одновременно заходят в систему и просматривают одну и ту же тему», в последнее время возникает довольно часто по мере роста популярности Discourse.
Возможно, нам потребуется внедрить новый режим поведения в таких случаях — вероятно, в интерфейсе темы должны появиться знаки «быстрая полоса» в какой-то форме…
Важно помнить, что реализации «чата» обычно транслируют фактическое содержимое подписчикам.
В Discourse у нас довольно сложный конвейер, из-за которого наивная реализация становится сложной и приводит к большому объему трафика.
Пользователь публикует ответ.
Все пользователи, просматривающие тему, узнают через трансляцию о новом содержимом.
Все пользователи запрашивают содержимое поста у сервера (100 зрителей = 100 запросов).
Мы загружаем изображения и оптимизируем их.
Все пользователи, просматривающие тему, узнают через трансляцию о новом содержимом.
Все пользователи запрашивают содержимое поста у сервера (100 зрителей = 100 запросов).
(у нас есть различные оптимизации, ограничения скорости, повторные попытки и так далее, но суть именно в этом).
Все эти запросы должны проходить через наш конвейер безопасности, чтобы убедиться, что у пользователя есть права на просмотр поста и так далее.
Если бы содержимое было коротким, и мы каким-то образом могли бы реализовать безопасность более легким способом для «быстрой полосы», то мы могли бы распространять сообщения чата через трансляцию. Это привело бы к значительно лучшей производительности: с такой архитектурой мы, вероятно, смогли бы обрабатывать 10 000 пользователей на одном недорогом Droplet DigitalOcean с 2 ГБ памяти.
Безопасность — очень сложная задача. Кэширование также сложно из-за проблем с инвалидацией кэша.
Так что да, мы определенно думаем над этой проблемой. Но на данный момент…
Много авторизованных зрителей в одной теме + много нового содержимого в одной теме = дорогие счета за сервер.
Если говорить честно, у меня знаний ровно столько, чтобы навредить. Я такой тип парня, который учится, играя (и ломая). Полностью оцениваю фантастические усилия, вложенные в создание этой платформы. Когда я создавал свой первый форум 12 месяцев назад, я создал 12 разных версий Vanilla, MyBB, SMF, Flarum и т. д. Discourse оказался самым лучшим.
Один из главных плюсов — активная разработка. Прекрасно видеть, как вы прислушиваетесь к сообществу и постоянно совершенствуете платформу.
Привет, ребята, мой сайт, похоже, деградировал: при том же тарифе Digital Ocean (8 ГБ, 4 CPU) он начинает испытывать трудности уже при 60–70 пользователях, публикующих 1000 сообщений.
Хотелось бы уточнить два момента.
Можно ли убрать сообщение об экстремальной нагрузке? Оно, кажется, больше пугает пользователей, чем помогает.
Есть ли какие-то успехи в решении проблемы с большим количеством пользователей?
Временно планирую поэкспериментировать с настройкой рабочих процессов (unicorns) и отключить плагины, чтобы освободить ресурсы.
Если у вас есть свободное место на диске, увеличение файла подкачки не нанесет вреда. Команда free покажет, как используется память и сколько места занято в файле подкачки.
Это более лично и предвзято, чем текстовые комментарии в газетах или на телеканалах.
Vanilla, MyBB, SMF, Flarum и т. д. Discourse оказался самым лучшим.
)