8

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

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

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

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

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

可以看到 oplog 观察需要很多时间

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

在此处输入图像描述

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

在此处输入图像描述

4

1 回答 1

1

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

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

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