javascript - 为什么在 meteor /蒙戈中观察 oplog 需要这么多时间？

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) .数据中心内的延迟可能非常非常高，这可能是您糟糕的集合读取的原因。正如其他评论者所注意到的那样，索引可能会起作用，但我敢打赌，这些集合中的任何一个记录都少于一百条，所以这并不重要。