У меня свежая установка Ubuntu 20 с Docker и Discourse. Я не устанавливал никаких плагинов, и в базе данных всего два пользователя, однако сборка занимает более 40 минут! Нет какой-то конкретной части процесса сборки, которая работала бы медленно — всё в целом занимает невообразимо много времени. У меня довольно мощный сервер, и он успешно обслуживает 20 сайтов моих клиентов, так что проблема не в производительности.
Зависает здесь минимум на 4 минуты:
warning Resolution field "lodash@4.17.21" is incompatible with requested version "lodash@4.17.15"
Сразу после этого снова зависает ещё на 4–5 минут:
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".
Я пробовал запускать сборку с флагом --skip-prereqs, но безрезультатно: каждая повторная сборка всё равно занимает более 40 минут.
Как вы думаете, что именно может вызывать эту проблему?
Мы наблюдаем регрессию времени сборки, вызванную новой возможностью запуска тестов тем через интерфейс. Мы тщательно отслеживаем эту проблему и пытаемся её исправить.
Спасибо за подтверждение, @Falco. У меня 1 ГБ ОЗУ (впритык, но для легковесного сайта мне никогда не требовалось больше). Сборка занимает более 30 минут (обычно около 10).
Райфаль, это регрессия в бета-версии 2.9.0 или в стабильной версии 2.8.0?
Возвращаясь к первому сообщению: кто-нибудь знает, откуда берётся это предупреждение?
Не знаю, стоит ли это действительно рассматривать, но лично я заметил во многих случаях, что производительность падает при использовании Ubuntu 20.04 (Discourse, веб-серверы, игровые серверы), даже при попытках оптимизации разными способами
В данный момент я запускаю Discourse на Droplet для тестов с теми же характеристиками; пересборка занимает около 8–12 минут (Ubuntu 18).
Это масштабное изменение, над которым мы работаем уже несколько лет, подходит к финальной стадии. В процессе его внедрения наступает период, когда «ситуация ухудшится, прежде чем станет лучше», и это один из таких «негативных» побочных эффектов.
Как только мы завершим переход всех новых установок на сборку Ember CLI в Production для всех существующих сайтов и полностью откажемся от старой конвейерной системы обработки ресурсов, мы сможем активно начать её модернизацию и, надеемся, получить выгоду от обновлений из основных веток.
Также существует возможность предоставить пользователям со слабыми процессорами возможность отключить source maps и другие «желательные, но не обязательные» функции, чтобы ускорить их пересборку.
Спасибо за обновление, @Falco У нас квадро-процессор с 8 ГБ ОЗУ на Linode, и обычно это отличная конфигурация, но сейчас это настоящий кошмар. Мы планировали внести ряд изменений, но теперь придется подождать, пока развертывание не вернется к нормальному, пусть и не идеальному, уровню скорости.
@Falco Я тоже замечаю, что в последних нескольких выпусках производительность сервера ухудшается: сайты загружаются дольше и потребляют больше памяти. За последние два года в моей настройке (плагины, оборудование и т.д.) ничего не менялось, и количество активных пользователей на сайте также осталось прежним. Есть ли способ объективно отслеживать производительность сайта изнутри Discourse, чтобы мы могли затем сообщить об этом здесь? На данный момент единственный известный мне способ — это когда я открываю сайт, и он загружается в первый раз более чем за 8 секунд (в более ранних сборках это всегда занимало менее 2–3 секунд).
Какие времена пересборки вы наблюдаете? Мне только что потребовалось выполнить пересборку из-за изменения SMTP, и для крошечного сайта (30 пользователей, 400 сообщений) это заняло чуть меньше 12 минут.
Эта тема посвящена «времени сборки», а не времени загрузки страниц. Если вы говорите об ухудшении времени отклика страниц, пожалуйста, откройте по этому поводу новую тему и предоставьте какие-либо данные.
Я, кажется, понял, почему страницы загружаются так долго. Параметр shared_db в app.yml был установлен равным объёму всей оперативной памяти системы. Сбросил его обратно на значение по умолчанию (25%), пересобрал проект, и теперь загрузка занимает меньше секунды.
Спасибо за обновление, 
У нас квадро-процессор с 8 ГБ ОЗУ на Linode, и обычно это отличная конфигурация, но сейчас это настоящий кошмар. Мы планировали внести ряд изменений, но теперь придется подождать, пока развертывание не вернется к нормальному, пусть и не идеальному, уровню скорости.