这是我的问题。
我有一个应用程序，用户可以在笔记本中存储笔记。
目前，当用户点击记事本时，我订阅了一个出版物，该出版物返回记事本的前5个音符。
因此，无论何时用户导航到新的记事本，都会设置新的订阅，并且该记事本的5个音符最终会以最小值结尾。因此，minimongo一次只有笔记集合中有5个笔记
为了改善用户体验，我更改了发布，因此在初始加载整个应用程序时，我订阅了一个发布，它返回所有记事本和每个记事本的前5个注释。所以现在在minimongo中我们总是有（5 x（记事本的＃））音符数量。
所以初始负载有点重，但我希望在那之后，在记事本之间导航要快得多。
因此，在加载时，我订阅了myInfo，它返回用户笔记本和每个记事本的第5个笔记。
然后，当您实际单击记事本时，我订阅myNotepadInfo，这也会返回记事本的前5个音符。由于初始订阅已经检索到此信息，因此minimongo中的所有文档都没有实际更改。但是我仍然想订阅myNotepadInfo，因为我有一个加载更多的注释机制，这取决于模板中的订阅。
所以我的应用程序完全正在使用这些更改，但我不确定幕后发生了什么，如果这种方法实际上有助于提高性能。我注意到改变后记事本如何加载的具体差异。
所以基本上我有第二个订阅与初始订阅重叠。
对我而言，似乎因为第二个订阅与初始订阅重叠，所以它必须将较少的文档传输到客户端，所以它应该更快？
答案 0 :(得分：0)
这方面的两个关键问题是（1）您向客户端发送了多少数据？ （2）您期望有多少用户？
第二点需要一些解释。 Meteor当前（2016）pub子架构的一个关键组件是在服务器上注册和跟踪客户端订阅。每个无法重复使用的附加订阅（即不与其他订阅重复）将增加应用程序的CPU要求。在这里，听起来每个用户“拥有”一个记事本（尽管可能不是这种情况）。如果是这样，那将意味着低订阅重用 - 每个用户将需要独立订阅来接收他/她的记事本，因为它们不能在用户之间重复使用。因此，每个用户的两个记事本订阅将有效地加倍由于记事本订阅而导致应用程序的CPU占用空间的一部分。
这不一定是坏事。如果您的应用程序是专为管理，内部服务或只是较少数量的用户而设计的，那么它可能不会产生明显的差异。对于面向消费者的应用程序，希望/期望高用户数，这将是一个糟糕的选择。
Kadira关于观察者重用is here的一篇好文章，我也推荐他们的（付费）Bulletproof Meteor文章。
最后，您可以查看一些旨在改善这些问题的Kadira工具，Subs Manager和Fast Render。你应该检查一下他们是否仍在积极维护 - 我没有。