我们有500万篇帖子，搜索速度相当快。托管配置为：2.8GHz Xeon E5-2680 处理器的6个共享vCore，16GB内存，以及SSD存储。不过，我并没有关于用户同时发起发帖数量的具体指标，因此可能存在锁竞争问题。
另一方面，发帖过程通常相当缓慢，可能需要6到7秒才能完成。不过，Discourse 在处理时会采用非阻塞方式，因此不会严重影响用户体验。
这……不太正常。
我认为在拥有数百或数千条帖子的任何主题上，这很可能都是如此。对于简短的主题，情况则不应如此。
我记得 @Wingtip 的论坛上有大量非常长的主题。
2 个赞
是的，我们确实如此。
6-7 秒的发帖时间是否仅针对大型主题？如果你回复一个已有 100 条回复的主题，是否也需要 6-7 秒？
我刚才无法复现——发布缓慢是间歇性的。这似乎与帖子数量无关。也许是有人同时发帖导致的锁定问题，或者其他原因。
7 篇帖子：非常快，和 meta 上差不多
500 篇帖子：可能稍慢一点，但不算太严重。大概 1.5 秒？
16k 篇帖子：似乎和 500 篇时差不多
1 个赞
而且我相信，如果大量用户同时访问某个超级话题，也会导致排队请求增多，从而拖慢整个 PG 服务器的性能。
这很有道理，优先考虑众多浏览帖子的用户体验，而非一两个试图发帖的人。
你现在的勇气值如何？介意暂时启用 mini_profiler 吗？它会在侧边显示耗时，这样我们就能帮你定位是哪条查询出了问题！
我刚才的这条帖子耗时 576 毫秒
最慢的查询是：
@riking 正在处理一个修复此问题的 PR 
6 个赞
启用它会对整体性能产生多大影响？是否可以在不重建站点的情况下启用？自从 PostgreSQL 12 变更以来，我一直无法成功完成重建，即使将其设置为继续使用 pg10 也是如此。
您需要将电子邮件地址设置为 app.yml 文件中的开发者邮箱。您可以通过销毁并重新启动容器来应用此更改，而无需重新构建。如果您已通过 discourse docker 升级对容器进行了更改，这些更改将会丢失。
您也可以在容器内编辑 config/discourse.conf 文件，然后
sv restart unicorn
1 个赞
鉴于重建失败，我担心一旦销毁容器就会彻底束手无策。昨天尝试升级 PostgreSQL 12 时出现了太多错误，因此在我确信不会导致网站长时间停摆之前，我实在不敢贸然进行任何更改。
1 个赞
嗯，免费建议的价值取决于你付了多少，但这样做通常很安全：
cd /var/discourse
./launcher enter app
vi config/discourse.conf
# 在 vi 中，将 developer_emails 这一行修改为你的邮箱地址，然后退出 vi
sv unicorn restart
# 在 Web 服务器重启并开始提供页面所需的 30-90 秒内，你可能会感到一阵恐慌
不过，你仍然可能因此弄坏某些东西。我认为有可能把配置文件改得让 Discourse 无法启动。
sv restart unicorn 有效，但 sv unicorn restart 无效。
我大概有三分之一的时间会搞反。
不过，这已经是一种进步了，因为我以前有一半的时间都会弄错。
1 个赞
2 个赞
这是一个来自 app/models/user_stat.rb:159 的 update_topic_reply_count 方法中的 2 秒查询。
这正是 @riking 正在处理的问题。
5 个赞
太好了！任何对发帖时间的实质性改进都会让用户非常开心，这目前是抱怨最多的问题。不过我毫不怀疑，随后他们又会找到其他事情来抱怨。
3 个赞
如果你觉得好受点，我也抱怨过那个查询，因为我在 Meta 上有太多已读状态。我们每次回复都在做无意义的计数工作……
1 个赞
在我们从其他软件进行的测试导入中，有一个包含略超过 20 万条帖子的主题，我能够顺利地向该主题发帖。这说明关键不在于主题的大小，而在于进行发帖的用户。
1 个赞