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

【问题标题】：Why observing oplog takes so much time in meteor / mongo?为什么在meteor / mongo中观察oplog需要这么多时间？
【发布时间】：2016-06-08 15:14:08
【问题描述】：

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

问题是：因为我一直在使用它，我所有的出版物都需要更多的时间才能完成。当它只需要 200 毫秒时，这不是问题，但通常需要更多时间，比如这里，我订阅了我描述的出版物 here。

该出版物的响应时间已经过长，并且 oplog 观察也在减慢它，尽管它远不是唯一一个观察 oplog 需要这么长时间的出版物。

谁能向我解释发生了什么？我在网络上的任何地方都找不到任何解释为什么观察 oplog 会减慢我的发布速度。

这里有一些来自 Kadira 的截图来说明我在说什么：

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

最后，观察 oplog 需要合理的时间（但仍然会减慢我的 pub/sub）：

【问题讨论】：

你见过这个吗？是你的情况吗？ stackoverflow.com/questions/23429049/…
是的，我知道，但这不是我的问题。我的问题是：虽然 oplog 拖尾应该在我的服务器上节省资源和时间，但为什么在我的某些 pusub 上以一种明显随机的方式花费这么多时间？就像我在上面展示的那样，观察 oploags 需要 1100 毫秒 + 2800 毫秒……。当它应该是改进我的应用程序的一种方式时，放慢我的发布速度是不可接受的。
您的收藏中有多少文档？您是否使用带有ensureIndex 的索引？你获取文件的时间真的很长docs.mongodb.com/manual/reference/method/…
嗨，David Panart，您找到这个问题的答案了吗？
绝对没有：/它只是一个足够小的问题，所以我不再关心，现在有更多的可能性来优化 Meteor 项目，例如 Cult Of Coders 的 redis-oplog

标签： javascript mongodb meteor mongodb-oplog

【解决方案1】：

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

您可能正在做很多您没有意识到的事情会使发布变慢：

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

【讨论】：