Наш сайт на Discourse насчитывает более 10 тысяч пользователей и около 700 активных пользователей в день. Пользователи отправляют в среднем 10 тысяч сообщений в день. Наше сообщество генерирует более 160 тысяч просмотров страниц в день, включая поисковых роботов и анонимных пользователей. Почти все наши пользователи подключаются к нам через мобильные устройства.
Мы запускали сообщество в режиме автономной установки на одном VPS с 16 ядрами CPU и 24 ГБ оперативной памяти, настроив файл app.yml со следующими значениями:
При такой конфигурации некоторые пользователи сообщают о медленной загрузке сайта, а иногда при отправке сообщения экран становится пустым (шапка при этом отображается). Кроме того, в часы пик производительность сайта иногда снижается.
Пожалуйста, объясните, допустили ли мы ошибку в конфигурации или нам нужно больше ресурсов.
Большое спасибо
10 тысяч постов в день — это довольно много по сравнению с количеством просмотров страниц. Учитывая вашу конфигурацию, я могу представить, что вы упираетесь в ограничения ресурсов, и, скорее всего, проблема в базе данных. Вы можете попробовать перейти к настройке с несколькими контейнерами, фактически разгрузив воркеров Unicorn с основного сервера.
Это вполне возможно, но я бы сначала попробовал масштабировать горизонтально всё, что поддаётся такому масштабированию. Это также даст вам гораздо более чёткое представление о том, где находится «узкое место».
Большинство проблем с производительностью можно решить, просто добавив больше ресурсов. Сложность заключается в том, чтобы делать это разумно, чтобы сэкономить деньги (или, возможно, значительную сумму).
Спасибо за ваши экспертные знания и дружелюбные советы. Я обязательно изучу, как это реализовать. У меня есть ещё один вопрос: какие настройки следует применить в приложении для указанных выше характеристик (24 ядра процессора и 32 ГБ оперативной памяти)?
Текущие настройки подходят или лучше увеличить значения?
Трудно сказать, не проверив систему и не увидев, что происходит.
Поскольку вы упомянули, что большинство проблем возникает при отправке поста, проблема, скорее всего, связана с записями в базу данных. Я не думаю, что дальнейшее увеличение shared buffers значительно поможет, но вы можете попробовать. Я видел, как это значение поднимали выше 50% памяти (вопреки всем рекомендациям), так что вы можете попробовать постепенно увеличить его до 12 ГБ.
Если вы не наблюдаете ошибок 502, то нет смысла увеличивать и UNICORN_WORKERS.
Вы не упоминаете об этом, поэтому, как я думаю, первое, что я бы сделал, — это подключил CDN. Это значительно снизит нагрузку на VPS, так как большие запросы не будут обращаться к серверу.
В дополнение к CDN я бы также использовал S3-подобное хранилище, что позволит вам масштабировать хранилище и ресурсы VPS отдельно (если ваше сообщество активно загружает файлы).
Эти рекомендации сильно помогают снизить нагрузку, а рост стоимости при этом значительно меньше, чем при переходе на более мощный VPS.
Спасибо, @marianord. К сожалению, мы не используем CDN. Скорость загрузки на нашем форуме не очень высока. В основном пользователи обсуждают различные темы. Например, за последний год было опубликовано около 2,8 млн сообщений и получено 2,7 млн лайков, но загружено всего 25 ГБ файлов.
Как вы считаете, исходя из этой информации, использование CDN, подобного S3, снизит нагрузку на наш сервер?
Я не согласен с @marianord. Я не думаю, что CDN внесёт заметную разницу в нагрузку на ваш сервер.
Это просто статические файлы, и они вообще не создают нагрузки при отдаче.
S3 выгружает файлы и резервные копии на другой сервер, управляемый облачным провайдером (очень общее описание).
CDN кэширует статические файлы вашего сервера (изображения, JS, CSS) на множестве серверов (PoP) по всему миру, чтобы ускорить загрузку этих ресурсов.
По крайней мере, это мой опыт: вы уменьшаете количество запросов, поступающих на ваш сервер, тем самым снижая нагрузку. Гораздо проще обработать 10 JSON-запросов на пользователя, чем 100 запросов на пользователя.
Возможно, это не решит все проблемы, с которыми сталкивается @nildarar, но снизит серьёзную нагрузку на сервер, исключив все статические запросы (кэшированные) с сервера Discourse.
Запрос статического файла не оказывает значительного влияния на общую нагрузку сервера. Тяжелыми являются запросы динамического контента.
В общем случае json-запрос — это не статический ресурс, который может быть закэширован CDN. Это динамический контент, который генерируется на лету. Почему вы говорите о json-файлах в контексте CDN?
статические запросы ≠ более высокая нагрузка.
Извините, но это действительно плохой совет.
Вот пример с машины на 6 ЦП (таким образом, суммарная мощность ЦП составляет 600%), на которой запущен Discourse без CDN или S3.
Верно, но в Discourse есть несколько исключений, например, стили, которые обслуживаются через Ruby, поэтому наличие CDN с кэшированием означает, что такие запросы не расходуют процессы Unicorn.
Что касается проблемы, описанной в исходном сообщении, первое, что нужно сделать, — это привлечь специалиста для проведения анализа производительности в часы пик и выявления текущих узких мест.
Спасибо за ваши рекомендации. До нескольких месяцев назад мы использовали CDN-сервис Cloudflare и успешно оптимизировали статический контент с помощью правил страниц. Однако позже я где-то прочитал, что использование прокси-серверов, таких как Cloudflare, значительно снижает производительность Discourse, поэтому мы его отключили.
Вчера мы увеличили количество ядер процессора с 16 до 24 и внесли следующие изменения в файл app.yml:
Эти изменения временно решили нашу проблему, но я считаю, что в ближайшие несколько месяцев нам необходимо внести фундаментальные изменения.
Исходя из ваших рекомендаций, приоритетными мерами для повышения производительности являются использование CDN для раздачи статического контента и разделение Discourse на два отдельных контейнера.
Это может быть устаревшая информация, но я помню, что читал, будто Discourse предпочитает меньшее количество более мощных процессоров, а не большее количество менее мощных… даже если вы измените количество воркеров единорогов.
@codinghorror, можете ли вы подтвердить, что эта информация всё ещё актуальна?
По нашим прогнозам, в следующем году количество наших пользователей утроится, поэтому уже сегодня мы должны предоставить необходимые ресурсы для такого масштаба.
Использование таких инструментов, как Prometheus + Grafana, поможет вам отслеживать историю данных, а не только видеть их в реальном времени, после чего можно провести более глубокий анализ происходящего.
Снова здравствуйте
Следуя вашим советам, мы установили Prometheus и некоторое время отслеживали производительность сообщества. Пожалуйста, ознакомьтесь с отчетами ниже и сравните значения с теми, что вы видите в различных установках.
Недавно я прочитал в другом посте, что один сайт отказался от плагина «Кто онлайн» (Who’s Online), так как он якобы является причиной замедления работы.
