nildarar
(Nildarar)
1
我们的 Discourse 站点拥有超过 10,000 名用户，每日活跃用户约 700 人，日均发帖量约为 10,000 条。我们的社区日均页面浏览量超过 160,000 次（包含爬虫和匿名用户）。几乎我们的所有用户都通过移动设备与我们连接。
我们在单台 VPS 上以独立模式运行社区，该 VPS 配备 16 个 CPU 核心和 24GB 内存，并按照以下值配置了 app.yml：
params:
db_shared_buffers: "6GB"
db_work_mem: "50MB"
env:
UNICORN_WORKERS: 16
我们使用的插件包括：
docker_manager
discourse-solved
discourse-adplugin
discourse-voting
discourse-push-notifications
discourse-whos-online
discourse-akismet
discourse-data-explorer
discourse-sitemap
discourse-telegram-notifications
在上述配置下，部分用户反映网站加载缓慢，有时在提交帖子时屏幕会变空白（但标题栏仍然显示）。此外，在高峰时段，网站性能偶尔也会变慢。
请说明我们的配置是否有误，或者是否需要更多资源。
非常感谢 
5 个赞
RGJ
(Richard - Communiteq)
2
每天10k篇帖子相对于页面浏览量来说相当高。根据您的配置，我想象您可能会遇到某些资源限制，我怀疑问题出在数据库上。您可以尝试迁移到多容器架构，从而将Unicorn工作进程从主服务器上卸载下来。
7 个赞
nildarar
(Nildarar)
3
根据您的回答，增加此配置中的资源并不能帮助我们解决问题？例如 24 个 CPU 核心搭配 32GB 内存。
1 个赞
RGJ
(Richard - Communiteq)
4
这完全有可能，但我建议先尝试将所有可以水平扩展的组件进行水平扩展。这样也能让你更清楚地了解瓶颈所在。
大多数性能问题只需增加更多资源即可解决。难点在于如何以明智的方式做到这一点，从而节省开支（甚至可能节省一大笔钱）。
10 个赞
nildarar
(Nildarar)
5
感谢您的专业建议和友好指导，我一定会去阅读关于如何实现这一点的资料。我还有另一个问题：针对我上面提到的规格（24 核 CPU 和 32GB 内存），应用程序中应该应用哪些设置？
当前的设置是否合适，还是最好增加这些数值？
3 个赞
RGJ
(Richard - Communiteq)
6
如果不检查系统并查看具体情况，很难下定论。
既然您提到大多数问题发生在提交帖子时，问题很可能出在数据库写入上。我认为进一步增加 shared buffers 可能不会有太大帮助，但您可以尝试一下。我曾见过有人将其调至超过内存的 50%（尽管这违背了所有建议），因此您可以尝试逐步将其提高到最多 12GB。
如果您没有遇到 502 错误，那么增加 UNICORN_WORKERS 也没有意义。
4 个赞
marianord
(Mariano Rodriguez)
7
你没有提到使用它，所以我认为，我首先会做的是添加一个 CDN，这将大大减轻 VPS 的负担，因为较大的请求不会触及服务器。
除了 CDN，我还建议使用类似 S3 的存储服务，这样你可以独立扩展存储和 VPS 资源（如果你的社区上传量很大）。
这些建议非常有助于降低负载，而且价格增幅远低于升级更大的 VPS。
2 个赞
nildarar
(Nildarar)
8
感谢 @marianord，很遗憾，我们并未使用 CDN。我们论坛的上传速率并不高。大多数时候，用户讨论各种话题。例如，在过去一年中，我们发布了约 280 万条帖子，获得了 270 万个赞，但上传的文件总量仅为 25GB。
您认为，根据我所提供的信息，使用像 S3 这样的 CDN 能否减轻我们服务器的负载？
RGJ
(Richard - Communiteq)
9
我不同意 @marianord 的观点。我认为 CDN 不会对你的服务器负载产生明显影响。这些只是静态文件，提供起来完全不成问题。
1 个赞
marianord
(Mariano Rodriguez)
10
CDN 和 S3 是两种不同的服务。
- S3 将文件和备份卸载到由云提供商管理的另一台服务器上（非常简化的概述）。
- CDN 将服务器的静态文件（图片、JS、CSS）缓存到全球多个服务器（PoP）上，以加速这些资源的加载。
至少根据我的经验，通过减少到达服务器的请求数量，从而降低了负载。每个用户只处理 10 个 JSON 请求比处理 100 个请求要容易得多。
这可能无法解决 @nildarar 面临的所有问题，但通过从 Discourse 服务器移除所有静态请求（即已缓存的请求），可以显著减轻服务器的重负载。
3 个赞
RGJ
(Richard - Communiteq)
11
静态文件的请求对整体服务器负载的影响不大。动态内容的请求才是负担较重的部分。
通常，json 请求并非可由 CDN 缓存的静态资源，而是动态生成的内容。你为何在 CDN 的语境下讨论 JSON 文件？
静态请求 ≠ 较重负载。
很抱歉，这实在是不好的建议。
以下是一个运行 Discourse 但未使用 CDN 或 S3 的 6 核 CPU 机器的示例（因此 CPU 总容量为 600%）。
你可以看到，nginx 仅占 6.7%（即总容量的 1/100）。其中只有一部分用于静态资源。
即使我们将静态资源卸载到 S3 和/或 CDN，整体服务器负载的降低幅度也不到 1%。
3 个赞
Falco
(Falco)
12
确实，但 Discourse 有一些例外情况，比如由 Ruby 提供的样式表，因此使用缓存 CDN 意味着这些请求不会占用 Unicorn 进程。
关于原始发帖人提出的问题，首先需要的是由具备相关知识的人员在高峰时段进行性能分析，并确定当前的瓶颈所在。
7 个赞
marianord
(Mariano Rodriguez)
13
我的意思是，JSON 请求会访问服务器，而静态请求则不会。
1 个赞
nildarar
(Nildarar)
14
感谢您的指导。直到几个月前，我们还使用 Cloudflare CDN 服务，并通过页面规则对静态内容进行了有效的优化。之后，我读到一些资料称，使用像 Cloudflare 这样的代理会显著降低 Discourse 的性能，因此我们将其禁用了。
昨天，我们将 CPU 核心数从 16 增加到 24，并在 app.yml 中进行了以下更改：
params:
# db_shared_buffers: "6GB"
db_shared_buffers: "7GB"
env:
# UNICORN_WORKERS: 16
UNICORN_WORKERS: 24
通过这些更改，我们的问题暂时得到了解决，但我认为在未来几个月内，我们需要进行根本性的调整。
因此，根据您的建议，使用 CDN 提供静态内容以及将 Discourse 拆分为两个独立的容器，在性能优化方面具有更高的优先级。
1 个赞
SouperC
(NotSoSuper)
15
这可能是过时的信息，但我记得读过 Discourse 更倾向于使用数量较少但性能更强的 CPU，而不是数量较多但性能较低的 CPU……即使你增加了 Unicorn 工作进程的数量。
@codinghorror，你能确认这些信息是否仍然准确吗？
3 个赞
RGJ
(Richard - Communiteq)
16
是的，没错，核心 CPU 性能确实很重要，但它主要提升的是整体速度。
@nildarar 遇到的是性能瓶颈，这需要采取不同的解决思路。
5 个赞
nildarar
(Nildarar)
17
有什么专门用于识别话语性能瓶颈的工具吗？
按 CPU 使用率排序的 htop 屏幕
我们预测明年用户数量将增长三倍，因此从今天起，我们必须为这一规模提供必要的资源。
marianord
(Mariano Rodriguez)
18
使用像 Prometheus + Grafana 这样的工具可以帮助您获取历史数据，而不是仅实时查看，从而对当前发生的情况进行更深入的分析。
4 个赞
nildarar
(Nildarar)
19
大家好 
按照您的建议，我们安装了 Prometheus 并监控了一段时间的社区性能。请查看下方的报告，并与您在不同安装环境中看到的数值进行核对。
4 个赞
