サイト速度を上げるコマンドはありますか?

There are commands like rake posts:rebake (i.e after migration).

Are there any others or something else that will speed up the forum? I have an impression that after changing the hosting with more RAM it is probably even slower… More GB didn’t help even though I’m checking without any traffic. I’m wondering if there are any commands that optimize the database, etc. because maybe that’s why moving through the links is terribly long and slow (1-2 sec) . It’s a bit disqualifying compared to nodebb, for example.

「いいね!」 2

If you change the ram in your server you need to run discourse-setup again to adjust the memory settings.

How big is your database? Is this an import or a new community? How fast is the processor? Single core cpu speed is critical. You have SSD and not spinning disks, right?

「いいね!」 8

Tests lightsail instances of 2 GB RAM, 1 vCPU, 60 GB SSD

I think the settings are correct:

UNICORN_WORKERS: 4
db_shared_buffers: "256MB"

Can you brighten up ?

「いいね!」 2

Lightsail is really aimed at simple web apps and websites.

You have one CPU core, so that means 2 unicorn workers, but your shared_buffers could be upped to 512MB. Your app.yml should include this comment:

With 2GB we recommend 3-4 workers, with 1GB only 2

So you’re using twice as many workers with half the recommended buffer size.

Spinning discs are what came before SSD, although you may also know them as hard drives or HDD. They’re too slow for Discourse.

「いいね!」 4

These settings are usually set automatically by discourse-setup based on the system specs (number of CPU cores, amount of RAM) at the time that script is run. It’s also safe to run it again if your server specs change.

「いいね!」 8

You want to say that it is much better to invest in the cheapest EC2 with two cores instead (later possibly combine it with ELB) ?

That’s what I can see, every server on aws is non-HDD

There are many differences on AWS instance types. Some use EBS backed disks which go into the network for disk access making latency higher. Some have fast local NVME drives, but they don’t persist data. Also there is the Z and C instance type families with way faster data.

However, all that ends up more complicated and expensive than a Digital Ocean droplet, which have acceptable performance for small communities for $5 and offer a pretty fast CPU in their $40 CPU optimized offering.

「いいね!」 2

Which exactly offer do you mean by optimized?

By the way, my question also applies to the commands themselves. That is, which commands (like “rake” rebake posts) should i run to optimize / rebuild posts / clear unnecessary files etc.?

There is no such thing :sweat_smile:.

Why would there be a secret command to make things fast? Why on earth would we default to a slow mode?

If you are having performance issues you need to bring hard data. What is the slow route, what is the community size, what is the database size, did you try removing all plugins and themes, did you try running in a $5 DO droplet, etc.

「いいね!」 12

There is prior art :rofl:

「いいね!」 6

no intention to blame anyone, especially as i haven’t looked into it myself, particularly the postgres instance/config … but discourse is damn slow. not sure what’s responsible for that, i guess the ruby ORM has its part.

of course you can always add a bigger iron, more ssd’s, more ram … up to a certain point, but that doesnt change the main point: discourse is pretty demanding/slow, even for tiny installs it requires a decent host

「いいね!」 1

Really? Can you back that up with numbers please?

In comparison to what and in what circumstances?

Do you regard Meta as slow?

「いいね!」 4

I really disagree with this statement. I know a number of small communities who run on a $5 VPS. A slow discourse installation is usually indicative of poor host selection, or misconfiguration.

Remember that Discourse isn’t a website, it’s an application, once loaded in your browser the data being relayed back and forth is minimal.

If you follow the standard installation guide, which is the only installation we support here, then all of the tuning for CPU/RAM is done automagically. You haven’t given us any examples or comparators here, I would strongly encourage you to provide us with some specifics.

「いいね!」 2

i can do some benchmarks, sure. I run it on a $5 virtualisation, with really minimal hardware for todays standards, i’m aware of that. And i wasn’t comparing it to other forum solutions, but i know what postgres can handle/deliver even when run in a docker container in a virtualisation, i have almost 20 years of experience in database development

okay okay, and i was a bit triggered by the “do you run it on hardware from the last century, aka spinning drives” attitude :slight_smile:
i rephrase to “discourse is more demanding than simpler systems”

「いいね!」 4

comment was a bit to harsh, agreed. see above

「いいね!」 2

Ca You say what the word misconfiguration means. It means what you can really do wrong by installing a clean forum and adding max 1-2 plugins. What configuration are you talking about?

「いいね!」 1

@eextra a few things come to mind…

What do you consider to be adequate performance
Describe the scenarios that slow performance is occuring.
How have you determined that the discourse platform (or even your hosting) is the source of the slow performance. That the database is a limiting factor etc.

Perhaps you could share a couple of webpagetest.org links as a starting point.

While that’s technically fair I think it misses the point from a community growth and UX perspective. There’s a lot to be said for the amount of traffic our communities attract from search.

IMO it’s important that their first visit to that link loads quickly.

And it does - excluding asset heavy communities such as NPN I don’t really see any Discourse communities with finished load times over two seconds, and the DOMContentLoaded is typically well under 1000ms.

WebPageTest is a terrible metric, open a browser, inspect the page source and swap to the network tab, empty the cache and force a hard reload. All the numbers are right in front of you.

You’re suggesting there’s a problem, but you aren’t giving us any examples. It would be really good if you could substantiate these claims.

It’s a perfectly valid tool that can be used as a starting point, or to delve deeper into specific scenarios (OS, location, bandwidth, latency) if you wish. It’s also a convenient way to share a result from a controlled scenario for others to look at.

Network tab is also perfectly valid as long as you understand that you are seeing literally just “your” experience, likely from your desktop over whatever connection you are on. It’s a good litmus test, it takes but a few seconds and it may or may not give you what you need to optimize for your visitors.

Both have merit. Neither are a “terrible metric” at all.

@eextra also worth mentioning that you should have a response time counter visible when you’re logged into discourse as an admin. You also have the ability to log NGINX performance reports via the admin panel.

ウェブサイトの速度テストサイトがなぜ悪いとされるのでしょうか?

私はこれらを頻繁に利用しており、非常に役立っていると感じています。特に、複数の地域からテストを実行し、1回のテストで複数回計測を行うサイトは有用です。

面白いことに、100〜200ms 程度の最適化に関する結果については、これらのサイトとブラウザで異なる値が得られることがありますが、それ以上の時間差については正確なようです。

時には、速度テストサイトで良好な結果が出るような最適化を選ぶこともあります。複数のサイトが似たような計測結果を出している場合、Google も同様の評価をしていると推測するからです(ただし、Google のアルゴリズムは非公開なので、この推測が正しいとは限りません)。

Ruby は famously 低速な言語として知られており、Discourse は膨大な量の JavaScript を使用しています。Discourse フォーラムの初期読み込み時間が長いこと、モバイルでの速度が遅いことは、広く議論されている事実です。適切なハードウェアがあれば高速な結果が得られると人々に伝えることは、必ずしも正確ではないと思います。今まさに Meta を閲覧していますが、Go で書かれたフォーラムに比べると確かに遅いですからね(笑)。私は Discourse を使っていますが、それは機能性、優れたスパム対策、豊富な機能、そしてメンテナンスの容易さからです。速度については、これまで「速い」と考えたことはありませんし、大多数のフォーラム利用者も、Google の検索結果から初めてリンクをクリックしてサイトを訪れる際、それを「アプリ」とは考えていません。