有一些命令，例如 rake posts:rebake（即迁移后）。
还有其他命令或其他方法可以加速论坛吗？我有个印象，在更换了拥有更多 RAM 的主机后，论坛反而变得更慢了。增加 GB 内存并没有帮助，即使我是在没有流量的情况下进行测试的。我在想是否有可以优化数据库等的命令，因为这可能是导致点击链接时速度极慢（1-2 秒）的原因。与 NodeBB 等相比，这确实有些令人失望。
如果您更换了服务器的内存，需要再次运行 discourse-setup 以调整内存设置。
您的数据库有多大？这是导入数据还是新社区？处理器速度如何？单核 CPU 速度至关重要。您使用的是固态硬盘（SSD）而非机械硬盘，对吗？
测试 Lightsail 实例配置：2 GB 内存、1 vCPU、60 GB SSD
我认为设置是正确的：
UNICORN_WORKERS: 4
db_shared_buffers: "256MB"
您能帮忙分析一下吗？
Lightsail 主要针对简单的 Web 应用和网站。
你只有一个 CPU 核心，因此意味着只能运行 2 个 Unicorn worker，但你的 shared_buffers 可以提升至 512MB。你的 app.yml 应包含以下注释：
对于 2GB 内存，我们建议配置 3-4 个 worker；对于 1GB 内存，则仅建议 2 个。
因此，你使用的 worker 数量是推荐值的两倍，而缓冲池大小却只有一半。
机械硬盘是 SSD 出现之前的存储介质，你可能也称之为硬盘驱动器或 HDD。它们的性能对于 Discourse 来说太慢了。
这些设置通常由 discourse-setup 根据运行该脚本时的系统规格（CPU 核心数、内存容量）自动配置。如果您的服务器规格发生变化，再次运行该脚本也是安全的。
你是想说，与其这样，不如投资最便宜的两核 EC2 实例（之后可能再结合 ELB 使用）吗？
从我看到的来看，AWS 上的每台服务器都不使用 HDD。
AWS 实例类型之间存在诸多差异。某些实例采用 EBS 支持的磁盘，磁盘访问需经过网络，导致延迟较高。某些实例配备高速本地 NVMe 驱动器，但数据无法持久化。此外，还有 Z 系列和 C 系列实例家族，其数据传输速度更快。
然而，这些方案的复杂度和成本最终都高于 DigitalOcean 的 Droplet。对于小型社区而言，$5 的 Droplet 性能已可接受，而其$40 的 CPU 优化型方案则提供了相当强劲的 CPU 性能。
您提到的“优化”具体是指哪个方案？
顺便一提，我的问题也适用于命令本身。也就是说，我应该运行哪些命令（例如“rake rebake posts”）来优化/重建帖子或清理不必要的文件等？
根本不存在这样的东西 
。
为什么会有某种“秘密命令”能让系统变快？我们怎么可能默认采用慢速模式呢？
如果你遇到性能问题，请提供确凿的数据。具体是哪些操作变慢了？社区规模多大？数据库有多大？你是否尝试过移除所有插件和主题？是否尝试过在 $5 的 DigitalOcean 实例上运行？等等。
早有先例了 
无意指责任何人，尤其是我自己尚未深入调查，特别是 PostgreSQL 实例和配置……但 Discourse 确实非常慢。不确定具体是什么导致了这种情况，我猜 Ruby ORM 也有一定责任。
当然，你总是可以升级硬件，比如更大的服务器、更多的 SSD 或更多的内存……但这只能改善到一定程度，并不能改变核心问题：Discourse 资源消耗大且运行缓慢，即使是小型部署也需要一个性能不错的服务器。
真的吗？能提供数据支持吗？
是跟什么比较，在什么情况下？
你觉得 Meta 慢吗？
我确实不同意这个说法。我认识不少小型社区，它们运行在 5 美元的 VPS 上。Discourse 安装运行缓慢，通常表明主机选择不当或配置有误。
请记住，Discourse 不是一个网站，而是一个应用程序；一旦在浏览器中加载，其来回传输的数据量非常小。
如果您遵循标准安装指南（这是我们在此唯一支持的安装方式），那么所有针对 CPU 和内存的调优都会自动完成。您尚未提供任何示例或对比数据，我强烈建议您提供一些具体信息。
当然，我可以做一些基准测试。我在一台5美元的虚拟化服务器上运行它，按照今天的标准，硬件配置确实非常低，这一点我清楚。我并不是在与其他论坛解决方案做比较，但我知道 PostgreSQL 即使在 Docker 容器中运行于虚拟化环境时也能处理/提供什么，我在数据库开发领域有近20年的经验。
好吧好吧，我确实有点被“你是不是在用上个世纪的硬件，也就是机械硬盘”这种态度触动了 
我重新表述为：“Discourse 比更简单的系统要求更高”。
评论确实有点太严厉了，同意。见上文。
你能说说“配置错误”这个词是什么意思吗？它指的是你在安装一个干净的论坛并最多添加 1-2 个插件时可能真正出错的地方。你所说的配置是指什么？
@eextra 有几点让我想到……
你认为什么样的性能才算达标？
请描述出现性能缓慢的具体场景。
你是如何确定是 Discourse 平台（甚至是你的托管服务）导致性能缓慢的？例如，是否确认数据库是瓶颈等。
或许你可以分享几个 webpagetest.org 的链接作为起点。
虽然这在技术上没错，但我认为从社区增长和用户体验的角度来看，它忽略了关键点。我们的社区从搜索引擎吸引大量流量，这一点非常重要。
在我看来，确保用户首次访问该链接时加载迅速至关重要。
事实确实如此——排除像 NPN 这样资产繁重的社区，我几乎没见过任何 Discourse 社区的页面加载时间超过两秒，而 DOMContentLoaded 通常远低于 1000 毫秒。
WebPageTest 并不是一个可靠的指标。打开浏览器，检查页面源代码，切换到网络标签页，清空缓存并强制硬刷新。所有数据都摆在你面前。
你提出了问题，但没有提供任何实例。如果你能证实这些说法，那将非常有帮助。
它是一个完全有效的工具，可以作为起点，或者如果您愿意，还可以深入探讨特定场景（操作系统、位置、带宽、延迟）。它也是一种便捷的方式，可以将受控场景下的结果分享给他人查看。
只要您明白，网络标签页展示的仅仅是“您”的体验，很可能是通过您当前使用的连接在桌面端看到的，那么它同样完全有效。它是一个很好的试金石，只需几秒钟，但它可能无法为您提供优化访客体验所需的全部信息。
两者各有可取之处。它们绝非“糟糕的指标”。
@eextra 另外值得一提的是，当您以管理员身份登录 Discourse 时，应能看到响应时间计数器。您还可以通过管理面板记录 NGINX 性能报告。
网站速度测试站点有什么不好的呢？
我想补充一点自己的看法，因为我经常使用这些工具，觉得它们很有帮助。尤其是那些支持多地点测试、并在一次运行中进行多次测试的站点。
有趣的是，在涉及100-200毫秒优化的情况下，我从这些站点得到的结果与浏览器中的结果有所不同，不过对于超过这个时间范围的测量，它们似乎相当准确。
有时我会选择一些能让网站速度测试站点满意的优化方案，因为如果这些站点都报告相似的测量结果，我就会假设谷歌也是这么认为的——当然，我可能错了，毕竟谷歌的算法是封闭的。
Ruby 以运行缓慢而闻名，Discourse 使用了大量的 JavaScript，因此其论坛的初始加载时间较长、移动端速度较差，这一点几乎没有争议。我认为告诉人们“只要硬件合适就能获得出色的速度表现”并不准确。比如我现在正在浏览 Meta 网站，与用 Go 编写的论坛相比，它的速度确实较慢（哈哈）。我使用 Discourse 只是因为它运行稳定、反垃圾功能强大、功能丰富且维护成本低。不过，我从未认为它速度快，大多数论坛访客在点击 Google 搜索结果中的第一个链接访问该网站时，也不会把它当作一个“应用”来体验。