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

Question

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

问题是：自从我使用它以来，我的所有出版物都需要更多时间才能完成。当它只需要200毫秒时，这不是一个问题，但它通常需要更多，就像在这里，我订阅我所描述的出版物here。

这个出版物的响应时间已经太长了，而且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，您的数据库可能与您的网络主机（我假设为Galaxy或Modulus）位于同一数据中心内。数据中心内部延迟可能非常非常高，这可能是您的不良收集读数的解释。正如其他评论者所注意到的那样，指数可能会发挥作用，但我敢打赌，你在这些收藏品中只有不到一百条记录，所以它并不重要。