Есть ли команды, которые ускорят работу сайта?

Поддержка
1

Есть такие команды, как rake posts:rebake (например, после миграции).

Есть ли какие-то другие команды или что-то ещё, что ускорит работу форума? У меня сложилось впечатление, что после переезда на хостинг с большим объёмом оперативной памяти форум стал работать даже медленнее. Увеличение объёма дискового пространства не помогло, хотя я проверяю работу без какой-либо нагрузки. Мне интересно, есть ли команды для оптимизации базы данных и т.п., потому что, возможно, именно из-за этого переход по ссылкам занимает так много времени и происходит очень медленно (1–2 секунды). Это немного дискредитирует систему по сравнению, например, с NodeBB.

2

Если вы меняете оперативную память на сервере, вам нужно снова запустить discourse-setup, чтобы настроить параметры памяти.

Каков размер вашей базы данных? Это импорт или новое сообщество? Насколько быстрый процессор? Критически важна одноканальная скорость CPU. У вас SSD, а не вращающиеся диски, верно?

3

Тестирую экземпляры Lightsail с 2 ГБ ОЗУ, 1 vCPU и 60 ГБ SSD

Думаю, настройки верны:

UNICORN_WORKERS: 4
db_shared_buffers: "256MB"

Можете прояснить ситуацию?

4

Lightsail действительно предназначен для простых веб-приложений и сайтов.

У вас одно ядро процессора, что означает 2 воркера unicorn, но ваш shared_buffers можно увеличить до 512 МБ. В вашем файле app.yml должен быть включен следующий комментарий:

При 2 ГБ мы рекомендуем 3-4 воркера, при 1 ГБ — только 2

Таким образом, вы используете вдвое больше воркеров при половине рекомендуемого размера буфера.

Вращающиеся диски — это то, что было до SSD, хотя вы также можете знать их как жёсткие диски или HDD. Они слишком медленные для Discourse.

5

Эти параметры обычно устанавливаются автоматически скриптом discourse-setup на основе характеристик системы (количество ядер процессора, объем оперативной памяти) во время выполнения скрипта. Также безопасно запускать его повторно, если характеристики вашего сервера изменились.

6

Вы хотите сказать, что гораздо выгоднее инвестировать в самый дешёвый экземпляр EC2 с двумя ядрами (позже, возможно, объединить его с ELB)?

Именно это я и вижу: каждый сервер на AWS не использует HDD.

7

Существует множество различий между типами экземпляров AWS. Некоторые используют диски на основе EBS, которые подключаются к сети для доступа к диску, что увеличивает задержку. Другие имеют быстрые локальные NVMe-диски, но данные на них не сохраняются. Также существуют семейства экземпляров Z и C, предлагающие значительно более высокую скорость работы с данными.

Однако всё это оказывается более сложным и дорогим решением, чем дроплет DigitalOcean, который обеспечивает приемлемую производительность для небольших сообществ за $5 и предлагает довольно быстрый процессор в своём тарифе с оптимизацией под CPU за $40.

8

Что именно вы имеете в виду под «оптимизированным» предложением?

Кстати, мой вопрос также касается самих команд. То есть, какие команды (например, «rake rebake posts») мне следует выполнить для оптимизации/пересборки постов, очистки ненужных файлов и т. д.?

9

Ничего подобного не существует :sweat_smile:.

Зачем вообще нужна какая-то секретная команда для ускорения работы? Почему бы нам по умолчанию не использовать медленный режим?

Если у вас возникают проблемы с производительностью, предоставьте конкретные данные. Что именно работает медленно, какой размер сообщества, каков размер базы данных, пробовали ли вы отключить все плагины и темы, пробовали ли вы запустить на droplet за $5 от DigitalOcean и т.д.

10

Есть прецедент :rofl:

11

Я не собираюсь никого обвинять, особенно потому, что сам ещё не разбирался в этом, в частности, в экземпляре PostgreSQL и его конфигурации… но Discourse чертовски медленный. Не уверен, что именно за это отвечает, но, думаю, Ruby ORM тоже вносит свою лепту.

Конечно, всегда можно добавить более мощное железо, больше SSD, больше оперативной памяти… до определённого предела, но это не меняет главного: Discourse довольно требователен и медлителен, и даже для небольших установок нужен приличный хостинг.

12

Правда? Можешь подтвердить это цифрами?

По сравнению с чем и в каких условиях?

Считаешь ли ты Meta медленной?

13

Я действительно не согласен с этим утверждением. Я знаю несколько небольших сообществ, которые работают на VPS за 5 долларов. Медленная установка Discourse обычно свидетельствует о плохом выборе хостинга или неправильной конфигурации.

Помните, что Discourse — это не веб-сайт, а приложение. После загрузки в браузере объём передаваемых данных минимален.

Если вы следуете стандартному руководству по установке, которое является единственным поддерживаемым здесь, то вся настройка CPU/RAM выполняется автоматически. Вы не привели нам никаких примеров или сравнений; я настоятельно рекомендую предоставить конкретные данные.

14

Я, конечно, могу провести бенчмарки. Я запускаю это на виртуализации за 5 долларов с действительно минимальным железом по современным меркам, и я это понимаю. И я не сравнивал это с другими решениями для форумов, но я знаю, на что способен PostgreSQL и что он может выдать, даже когда запущен в контейнере Docker на виртуальной машине — у меня почти 20 лет опыта в разработке баз данных.

Ладно, ладно, меня немного задело отношение «вы запускаете это на железе из прошлого века, то есть на вращающихся дисках» :slight_smile:
Я перефразирую: «Discourse более требователен, чем простые системы».

15

Комментарий был немного слишком резким, согласен. См. выше

17

Можете ли вы объяснить, что означает слово «неправильная конфигурация»? Имеется в виду то, что можно реально сделать не так при установке чистого форума и добавлении максимум 1–2 плагинов. О какой конфигурации вы говорите?

18

@eextra на ум приходит несколько вещей…

Какую производительность вы считаете достаточной?
Опишите сценарии, в которых наблюдается замедленная работа.
Как вы определили, что источником медленной производительности является платформа Discourse (или даже ваш хостинг)? Например, что база данных является ограничивающим фактором и т. д.

Возможно, вы могли бы поделиться несколькими ссылками с webpagetest.org в качестве отправной точки.

Хотя это технически верно, я считаю, что это упускает суть с точки зрения роста сообщества и пользовательского опыта (UX). Нельзя недооценивать количество трафика, который наши сообщества привлекают из поисковых систем.

На мой взгляд, важно, чтобы их первый переход по этой ссылке происходил быстро.

19

И это так — если не считать ресурсоёмких сообществ, таких как NPN, я не вижу ни одного сообщества на Discourse, где время полной загрузки превышало бы две секунды, а событие DOMContentLoaded обычно происходит значительно быстрее 1000 мс.

WebPageTest — крайне ненадёжный инструмент. Откройте браузер, просмотрите исходный код страницы, перейдите на вкладку «Сеть», очистите кэш и выполните принудительную перезагрузку. Все показатели прямо перед вами.

Вы утверждаете, что существует проблема, но не приводите никаких примеров. Было бы очень полезно, если бы вы могли подкрепить эти заявления фактами.

20

Это вполне допустимый инструмент, который можно использовать как отправную точку или для более глубокого анализа конкретных сценариев (ОС, местоположение, пропускная способность, задержка), если вы того пожелаете. Это также удобный способ поделиться результатом из контролируемого сценария, чтобы другие могли его изучить.

Вкладка «Сеть» также вполне допустима, если вы понимаете, что видите буквально только «свой» опыт, скорее всего, с вашего рабочего стола через то подключение, которое у вас есть. Это хороший лакмусовый тест: он занимает всего несколько секунд, но может, а может и не дать вам того, что нужно для оптимизации под ваших посетителей.

Оба подхода имеют свои достоинства. Ни один из них не является «ужасным метрическим инструментом».

@eextra также стоит упомянуть, что при входе в Discourse как администратор у вас должен быть виден счётчик времени отклика. Кроме того, вы можете вести логи отчётов о производительности NGINX через панель администратора.

21

Что плохого в сайтах для тестирования скорости загрузки веб-сайтов?

Хотел добавить своё мнение, так как я часто ими пользуюсь и считаю их полезными. Особенно те, которые проверяют из нескольких локаций и выполняют несколько тестов за один запуск.

Мне интересно, что результаты от таких сайтов отличаются от показателей моего браузера, когда речь заходит об оптимизациях, влияющих на 100–200 мс, хотя для более длительных временных интервалов они кажутся точными.

Иногда я выбираю оптимизации, которые радуют сайты для тестирования скорости, потому что, если все они показывают схожие результаты, я предполагаю, что и Google тоже. Хотя я могу ошибаться, так как его алгоритм закрыт.

Ruby печально известен как медленный язык, Discourse использует огромное количество JavaScript, и мало кто спорит с тем, что время первоначальной загрузки форума на Discourse велико, а скорость работы на мобильных устройствах низкая. Я считаю, что утверждение о том, что при правильном оборудовании можно получить отличные результаты по скорости, не совсем верно. В данный момент я, например, просматриваю Meta, и она действительно медленнее, скажем, форума, написанного на Go, lol. Я использую Discourse, потому что он хорошо работает, имеет отличную защиту от спама, множество полезных функций и требует минимального обслуживания. Однако я никогда не считал его быстрым, и большинство посетителей форумов тоже не воспринимают его как «приложение», когда переходят по первой ссылке из Google на этот сайт.