ビルドに非常に時間がかかっています

インストール
1

こんにちは。

Ubuntu 20、Docker、Discourse をクリーンインストールしました。プラグインは追加しておらず、データベースにはユーザーが 2 人しかいませんが、ビルドの完了に 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 分以上かかっています。

問題の原因となっている可能性のある特定のことはありますか？

ご協力ありがとうございます。

「いいね！」 6
2

リビルドにも時間がかかっていることに気づきました。RAMはいくつありますか？

「いいね！」 4
3

DO ドロップレット (1 GB メモリ / 25 GB ディスク / LON1 - Ubuntu 20.04 (LTS) x64) を再構築しました。

20:25,44 かかりました。

CPU は予想通り急上昇しました。

image
image1013×308 8.65 KB

メモリはランダムでした。

image
image1001×619 21.9 KB

帯域幅は予想外でした。

image
image1012×328 12.7 KB

「いいね！」 1
4

UI経由でテーマテストを実行できるようになったことで、ビルド時間にリグレッションが発生しています。これは、当社が綿密に追跡し、修正しようとしている問題です。

「いいね！」 8
5

4GBのRAM :+1: アップデートありがとうございます @Falco

「いいね！」 2
6

確認ありがとうございます、@Falco。当方1GB RAMです（ギリギリですが、軽量サイトにはこれで十分でした）。ビルドに30分以上かかっています（通常は10分程度です）。

Rafaelさん、これは2.9.0ベータ版か2.8.0安定版のどちらかのリグレッションですか？

最初の投稿に戻りますが、この警告はどこから来ているかご存知の方はいらっしゃいますか？

7

それが本当に考慮すべきことなのかどうかは分かりませんが、個人的には、多くのことで Ubuntu 20.04 を使用するとパフォーマンスが低下することに気づきました（Discourse、Web サーバー、ゲーム サーバー）。最適化を試みてもです :thinking:

現在、テスト用に同じ特性を持つ Droplet で Discourse を実行していますが、再構築には約 8 ～ 12 分かかります（Ubuntu 18）。

「いいね！」 1
8

インストールされているプラグインやテーマコンポーネントの数によっても、ビルド時間は変わります。

再構築にも時間がかかります。

すべての公式プラグインを読み込んでいるため、私のビルドには少し時間がかかります。

「いいね！」 1
9

わかっていますが、この場合はプラグインなしの「同等性」について話していました。

「いいね！」 1
10

ビルドがそれらの警告で「ハング」しているとは思いません。単にサイレントでビルドされており、警告はプロセスの として出力されます。

つまり、警告またはその根本的な問題は、長いビルド時間に寄与していません。

「いいね！」 3
11

これをどこで追跡できますか @Falco？これを知らせてくれてありがとう、私もたまたまこれを見つけたのですが、ここでは大変なことになっています。

「いいね！」 2
12

これは長年取り組んできた巨大な変更であり、最終段階に入っています。「良くなる前に悪くなる」期間があり、これはその「悪い」副作用の一つです。

New installs will default to Ember CLI builds in Production をすべての既存サイトで完了し、古いアセットパイプラインを剥がしたら、積極的に近代化を開始し、アップストリームの利益を収集できることを願っています。

また、CPUの遅いユーザーがソースマップやその他の「あれば嬉しい」機能をオプトアウトしてリビルドを高速化できるようにする可能性もあります。

「いいね！」 11
13

アップデートありがとうございます @Falco :heart: LinodeのクアッドCPU、8GB RAMで、通常は素晴らしいセットアップですが、今は悪夢です。いくつか変更を計画していましたが、デプロイが通常’ishの速度に戻るまで待つ必要があります。

14

@Falco また、ここ数回のリリースでサーバーのパフォーマンスが低下していることに気づきました。サイトの読み込みに時間がかかり、メモリ消費量が増加しています。過去2年間、私のセットアップ（プラグイン、ハードウェアなど）に変更はなく、サイトのアクティブユーザー数も同じです。Discourse内でサイトのパフォーマンスを客観的に監視し、ここに報告できる方法はありますか？現時点では、サイトを開いたときに初回読み込みに8秒以上かかることしかわかりません（以前のビルドでは常に2～3秒未満でした）。

15

再構築時間はどのくらいかかっていますか？ SMTPの変更により再構築が必要になったのですが、ユーザー30人、投稿400件の非常に小さなサイトで12分弱かかりました。

「いいね！」 2
16

このトピックは、ページの読み込み時間ではなく、「ビルド時間」に関するものです。ページの応答時間の低下について話している場合は、データとともに新しいトピックを開いてください。

「いいね！」 2
17

今朝の最後のビルドは約20分かかりました

18

アップデート後、ページの読み込み時間が通常の2〜3秒に戻りました（嬉しいサプライズです）。

19

うわっ。それは普通じゃない。

「いいね！」 2
20

ページの読み込みに時間がかかっている理由がわかりました。app.yml の共有データベースサイズが、システムの総メモリと同じ値に設定されていました。デフォルト値（25%）に戻し、再構築したところ、1秒未満で読み込めるようになりました。

「いいね！」 3