2

这是我的问题。

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

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

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

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

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

因此，在加载时，我订阅myInfo返回用户记事本和每个记事本的拳头 5 个笔记。

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

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

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

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

4

1 回答 1

0

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

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

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

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

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

于 2016-10-11T22:51:21.383 回答