Meteor 中的重叠订阅是否会使性能变差？

Question

这是我的问题。

我有一个应用程序，用户可以在其中将笔记存储在记事本中。

当前，当用户单击记事本时，我订阅了一个出版物，该出版物返回该记事本的前 5 个笔记。

因此，每当用户导航到新记事本时，都会设置一个新订阅，并且该记事本的 5 个笔记最终会出现在 minimongo 中。所以 minimongo 一次只有 5 个笔记在笔记集合中

为了改善用户体验，我更改了发布，因此在整个应用程序初始加载时，我订阅了一个发布，该发布返回所有记事本和每个记事本的前 5 个笔记。因此，现在在 minimongo 中，我们始终拥有 (5 x (# of notepads)) 数量的笔记。

所以初始负载有点重，但我希望在那之后，在记事本之间导航会更快。

所以在加载时我订阅了myInfo，它会返回用户的记事本和每个记事本的 5 个笔记。

然后当你实际点击一个记事本时，我订阅了myNotepadInfo，它也返回了记事本的前5个笔记。由于初始订阅已经检索到此信息，因此 minimongo 中的任何文档都没有实际更改。但我仍然想订阅myNotepadInfo，因为我有一个加载更多注释机制，这取决于模板中的订阅。

所以我的应用程序完全可以处理这些更改，但我不确定幕后发生了什么，以及这种方法是否真的有助于提高性能。我没有注意到更改后记事本加载方式的具体差异。

所以基本上我有第二个订阅，它与初始订阅重叠。

在我看来，由于第二次订阅与最初的订阅重叠，它必须向客户端传输更少的文档，所以它应该更快？

Answer 1

这方面的两个关键问题是（1）您向客户端发送了多少数据？ (2) 您预计有多少用户？

第二点需要一些解释。 Meteor 当前 (2016) pub sub 架构中的一个关键组件是客户端订阅在服务器上注册和跟踪。每个无法重复使用的附加订阅（即不重复另一个订阅）都会增加应用程序的 CPU 需求。在这里，听起来每个用户都“拥有”一个记事本（尽管可能并非如此）。如果是这样，这将意味着订阅重复使用率低——每个用户都需要一个独立的订阅来接收他/她的记事本，因为它们不能在用户之间重复使用。因此，每个用户两次记事本订阅将有效地使应用程序的 CPU 占用量因记事本订阅而增加一倍。

这不一定是坏事。如果您的应用程序是为管理、内部服务或只是为较少数量的用户而设计的，那么它可能不会产生明显的差异。对于一个面向消费者的应用程序希望/期望高用户数，这将是一个糟糕的选择。

Kadira 写的一篇关于观察者重用 is here 的好文章，我也推荐他们的（付费）Bulletproof Meteor 文章。

最后，您可以查看一些旨在改善这些问题的 Kadira 工具，Subs Manager 和 Fast Render。不过，您应该检查它们是否仍在积极维护中 - 我没有。