极端负载错误

“Due to extreme load, this is temporarily being shown to everyone as a logged out user would see it”

I run a website that features live threads during basketball games and have had issues with the server getting overloaded and showing this message during games (peak activity).

Is there any way to identify the best way to address the issue? Is it storage speed? Memory? CPU? Is there something I can do other than beefing up my server, or if I do during these times… what should I beef up?

2 个赞

Have fewer people use the forum? Better still would be to have them spread out their use rather than all doing it during the game.

But none of that is helpful. Since you know when the games are, you could beef up your server just during the game, or run multiple servers during the game behind a load balancer.

You need more and faster CPU cores and more Ram, so you can increase the number of web processes (Unicorn Workers) in order to deal with the peak traffic.

4 个赞

It is an area that @sam is actively working on. It does seem that newer versions of Discourse have regressed in this area, performance-wise.

That being said, the real solution is to use a live chat tool if you need live real time interactions for hundreds of people at the same time – though I continue to question how and why chat is “useful” when it’s scrolling so fast nobody can really see any of it, ala Twitch and YouTube streams. :man_shrugging:

2 个赞

This thread here describes the issue quite well.

This was my experience with a in match football forum before issues kicked in:

Digital Ocean
1 CPU 1 GB = 30 -40 users in chat like situation
2 CPUs and 2 GB= 70-80 users in chat like situation
4 CPUs and 8 GB = fine for 120 users and 1000 posts in 2 hours. Didn’t reach limit.

With Hetzner (Mirroring site)

My experience was:
3 CPU (CPX 21 AMD chip) and 4Gb = struggling with 20 users
2 CPU (Intel) and 8gb = no issue with 20 users.

I never got around to testing with more users.

The key thing is to improve the CPU and Ram. AND ALSO edit the app.yml file.

Add more unicrons in here, and also alter db_shared_buffers .

5 个赞

For sport forums it becomes closer to live text updates for games. People are not so much chatting (although it does occur to an extent, especially at half time), they are instead getting a live text commentary from fellow fans.

Many people will log onto the forum, just to read the live text. Seeing the thoughts and opinions of key match events by key people. Ranging from funny reactions to serious analysis.

If you missed the game, people log on, simply to read the event by event commentary. It great for people at work :wink: Its more personal/biased than the text commentary from Newspapers or TV channels.

6 个赞

That’s right. discourse-setup will do that if you run it on the upgraded server.

2 个赞

I hear you, it is something @sam @eviltrout and I have been looking at closely … the “hundreds of users logged in and browsing the same topic at the same time” situation has been coming up a fair bit recently as Discourse becomes more popular.

We may need to invite a new mode of behavior when this happens, “fast lane” signs should probably start appearing in the topic UI in some form… :warning:

4 个赞

An important thing to keep in mind here is that “chat” implementations generally broadcast the actual content to the subscribers.

In Discourse we have quite a complex pipeline which makes the naive implementation complex that leads to large amounts of traffic.

  1. User posts a reply
  2. All the users looking at the topic discover via broadcast that there is new content
  3. All users ask the server for post content (100 viewers = 100 requests)
  4. We pull images / optimize images
  5. All the users looking at the topic discover via broadcast that there is new content
  6. All users ask the server for post content (100 viewers = 100 requests)

(we have various optimisations, rate limits, retries and so on, but that is the gist)

These requests all have to run via our security pipeline to ensure the user has the rights to see the post and so on.

If the content was short-ish and we could somehow figure out how to do security in a more light-weight way for the “fast lane” then we could distribute the chatty messages via broadcast. This would lead to significantly better performance, we could probably handle 10000 users on a single low 2gb digital ocean droplet with that design.

Security is very complex. Caching is also complex cause of cache invalidation issues.

So, yes, we are absolutely thinking about this problem. But as it stands …

Lots of logged in viewers on one topic + lots of new content on one topic = expensive server bills.

7 个赞

Thats fantastic!

In all honesty I only have enough knowledge to be dangerous. I am the type of bloke who learns by playing (and breaking). Fully appreciate the fantastic effort in creating this platform. When I created my first forum 12 months back, I created 12 different versions :laughing: Vanilla, MyBB, SMF, Flarum etc. Discourse was easily the best.

One biggest pluses is the active development. Its great to see how you guys listen to the community and continually improve.

6 个赞

Do you have recommended settings for this?

1 个赞

各位,我的网站似乎倒退了,使用相同的 DO 套餐(8gb,4CPUs),我的网站在 60-70 位用户发布 1000 篇帖子时开始运行困难。

我只想问两件事。

  • 是否可以移除极端负载消息?它似乎比提供帮助更能引起用户的恐慌。

  • 在处理大量用户方面有进展吗?

与此同时,我将探索修改 unicorn,并禁用插件等以帮助释放资源。

如果您在安装后调整了大小,是再次运行了 discourse-setup 还是手动更改了设置?

我刚刚手动完成了,我应该运行 discourse setup 吗?

如果你进行了编辑,你需要重新构建(不确定 destroy/start 是否可以)。

1 个赞

所以只是为了确保我没有误解,在编辑了 yml 之后,我只是运行了 ./launcher rebuild app

我是否应该尝试运行 ./discourse-setup

(如前所述,我的知识刚好够用,但又不够精通 :sweat_smile:

应该没问题。Discourse-setup 会为您更改内存设置。如果您已完成此操作,则应该没问题。

1 个赞

只是为了确保并出于兴趣:您是否配置了交换空间?

我有一个 2gb 的交换文件,你们会推荐一个 8gb 的交换文件吗?(与内存量匹配?)

如果磁盘空间足够,更多的交换空间不会造成损害。free 命令会告诉你内存使用情况以及交换空间的使用量。

1 个赞