Meteor 更新集合中的大型文档会导致客户端冻结6-8秒

我收集了一份相对较大的文件；文档是一个具有约2000个元素的对象，每个元素本身都是一个小对象。当我在服务器上更新文档时，客户端会锁定6-8秒

我加入了日志记录，它告诉我服务器何时完成了对集合的更新，然后是6-8秒的冻结，接下来发生的事情是observeChanges在客户端运行，所有东西都重新开始运行

• 我已经在每100ms登录控制台的客户端中设置了一个超时。它在延迟期间停止触发，因此我认为我的客户端javascript都没有运行

• 延迟似乎与文档的初始加载时间相匹配（我尝试了不同大小的文档）

• 我用的是铁制路由器。我已经将日志记录到数据、waitOn和动作函数中：它们直到延迟之后才会触发。所以我认为路由器不是问题所在

• 更新集合的函数仅在服务器上运行，因此客户端仿真速度并不慢

• 这不是渲染：如果我只触发更新客户端，页面会快速重新渲染

• 我已经非常仔细地检查过了，我不认为我的任何客户机代码都在请求该文档，它唯一的find（）在启动时运行，而不是自动运行

• 我已将日志记录放在我的发布功能中：集合未被重新发布。我不是在运行自动发布

---

有什么想法可能是问题或想法，我可以进一步调查？文档更新时，它是否像不可避免的同步时间那样简单？我需要所有的数据，所以虽然我可以重新构造它，但我无法删除任何数据。

您可以尝试在响应计算中在客户端上记录Meteor.Status（）以查看它报告的内容吗？您是否大致了解正在同步的集合中的平均字节数？最后一个问题，当您更新集合时，您是否交换了整个数据集？如果是这样，您是否可以使用$set或选择器和修饰符的任何组合来更精确地了解您的更新？谢谢，有一些有趣的想法要查看。我还可以通过对数据进行字符串化并将其存储为单个文本文档，然后在从数据库读取数据时对其进行解析来解决这个问题。虽然数据中有很多对象，但它们非常小，所以它可以相当紧凑地打包（希望我能早点想到这一点…）