У нас только что был пик нагрузки: около 1500 одновременных (в основном анонимных) пользователей посетили одну страницу.
Форум перешёл в режим, когда всем участникам отображается предупреждение о высокой нагрузке.
Цифровой облачный сервер Digital Ocean с оптимизацией под процессор
Выделенные процессоры: 4 vCPU
ОЗУ: 8 ГБ
Рабочие процессы Unicorn: 10
Учитывая, что используется лишь около 50% оперативной памяти и мощности процессора, поможет ли увеличение количества рабочих процессов Unicorn для таких пиковых нагрузок от анонимных посетителей или нет?
Я увеличил количество воркеров до 24. Разницы нет (всё ещё появляется сообщение: «Из-за экстремальной нагрузки это временно отображается для всех так, как это видит авторизованный пользователь»), при аналогичном пике одновременных посетителей (99% анонимных) прямо сейчас:
@sam Есть ли идеи, как ещё больше оптимизировать систему для пиковых нагрузок от анонимных пользователей (например, если одна тема становится вирусной в социальных сетях)? В обоих описанных выше случаях у памяти и процессора ещё есть значительный запас (согласно данным DigitalOcean), и мы даже не достигли нагрузки 4, однако форум переходит в режим «экстремальной нагрузки», несмотря на утроение количества воркеров.
Я считаю, что монитор данных DO недостаточно чувствителен и в некоторой степени вводит в заблуждение. Я экспериментировал с экстремальной нагрузкой на Hetzner и Digital Ocean. На Hetzner, когда появлялось сообщение об экстремальной нагрузке, наблюдался короткий резкий пик, когда показатель доходил до 120%.
Это длилось, возможно, секунду, прежде чем показатель опускался до отметки 40–50%.
Я воссоздал то же самое на Digital Ocean, и, насколько я помню, использование процессора никогда не превышало 50% (но нельзя было изменить ось X до уровня секунд).
Мое предположение: уровень CPU в DO, возможно, представляет собой среднее значение за 5 или 15 секунд. Поэтому вы не видите этих коротких резких пиков.
Для более глубокого анализа нам понадобятся отчеты экспортера Prometheus.
Если у вас есть достаточно оперативной памяти и мощности процессора, вы всегда можете добавить больше рабочих процессов Unicorn — это позволит масштабироваться в периоды пиковых нагрузок. Главное — избегать использования файла подкачки (swap), так как это приведет к резкому падению производительности.
Похоже, что в таком случае страницу этой темы можно было бы кэшировать и отдавать статически в течение короткого периода, вообще не обращаясь к бэкенду. Не знаю, может ли Discourse это делать (то есть устанавливать заголовки управления кэшем при высокой нагрузке и отдаче контента анонимным пользователям), и есть ли в настройке DigitalOcean подходящий прокси-кэш в цепочке, но это идея для разработки, которая может быть worth of consideration, если я не совсем ошибаюсь и это ещё не реализовано.
Возможно, @sam уже об этом думал или делал, либо знает, почему это плохая идея!
Да, но я предлагаю перенаправлять только анонимных пользователей на кэшированную страницу с коротким временем ожидания (60 с?), чтобы снять с них нагрузку, надеясь, что остальная часть сайта продолжит работать в режиме чтения-записи.
Это было бы здорово. В настоящее время, если мы публикуем тему в нашем Telegram-канале с более чем 200 000 подписчиков, весь сайт Discourse переходит в режим «только для чтения» почти на час. При этом количество авторизованных пользователей составляет всего около 50 (99% трафика — анонимные пользователи).
Это уже реализовано: для анонимных пользователей на страницах списка тем и на страницах самих тем мы используем агрессивное кэширование напрямую в Redis с таймаутом 60 секунд.
Я попробую запустить Prometheus, чтобы найти узкое место, но, скорее всего, проблема в мониторинге DO, который отстает, как отметил @Alec. Если это так, то, полагаю, решение — перейти на более мощный сервер?
