为什么观察oplog在meteor/mongo中需要这么多时间？

Question

我有一个MongoLab集群,它允许我使用Oplog拖尾来改善我的Meteor.js应用程序的性能,可用性和冗余.

问题是:自从我使用它以来,我的所有出版物都需要更多的时间来完成.当它只需要200ms时,这不是问题,但它通常需要更多,就像在这里,我订阅我在这里描述的出版物.

这个出版物的响应时间已经太长了,而且oplog观察也在减慢它的速度,尽管它远远不是观察oplog花费那么多时间的唯一出版物.

谁能向我解释发生了什么？我在网上搜索的任何地方都找不到为什么观察oplog会减慢我的出版物的任何解释.

以下是Kadira的一些截图,用于说明我在说什么:

这是另一个pub/sub的截图:

最后,观察oplog需要一段合理的时间(但仍然会减慢我的pub/sub):

Answer 1

Oplog 拖尾速度非常快。Oplog 拖尾不是这里的问题。

您可能做了很多您没有意识到的事情，导致发布速度变慢：

• 逐一文档后跟更新循环：您可能正在调用正文中进行文档更新Collection.forEach。这是非常慢的，也是你在方法体中表现不佳的根源。每次您执行由数百个并发连接侦听的单个文档更新时，每个连接都需要更新；通过执行查询后一次更新一个，Mongo 和 Meteor 都无法优化，它们必须等待每个用户在每次更改时更新。这是你的表现的双渐近增长。解决方案：考虑如何使用{multi:true}.
• 每个用户的唯一查询：如果您对用户文档进行一次更改，例如连接到 100 个并发唯一订阅，则将连续通知连接。这意味着第一个连接将在 90ms 内收到通知，而最后一个连接将在 90ms * 100 个用户后收到通知。observeChanges这就是你速度慢的另一个原因。解决方案：考虑一下您是否确实需要对每个用户文档进行唯一的订阅。Meteor 对多个并发集合之间共享的相同订阅进行了优化。
• 许多文档：您可能将每个线程评论、帖子、聊天消息等编码为自己的文档。每个文档需要单独发送给每个客户端，从而引入一些相关的开销。对于关系数据库来说，这是正确的模式，对于基于文档的数据库来说，这是错误的模式。解决方案：尝试将向用户呈现页面所需的所有内容都包含在单个文档中（反规范化）。对于聊天，您应该有一个“对话”文档，其中包含两个以上用户之间的所有消息。
• 数据库与您的主机不在同一位置：如果您使用 MongoLab，您的数据库可能与您的 Web 主机不在同一数据中心（我假设是 Galaxy 或 Modulus）。数据中心内的延迟可能非常非常高，这可能就是您的集合读取不佳的原因。正如其他评论者所注意到的，索引可能会发挥作用，但我敢打赌，这些集合中的任何一个记录都少于一百条，所以这并不重要。