这就是我的问题。
我有一个应用程序,用户可以在记事本中存储笔记。
目前,当用户单击记事本时,我订阅了一个返回记事本前5个备注的出版物。
因此,每当用户导航到新的记事本时,就会设置一个新的订阅,并且该记事本的5个笔记将以minimongo结束。因此,minimongo在笔记集合中一次只有5个笔记
为了改善用户体验,我更改了发布,以便在整个应用程序的初始加载时,我订阅一个发布,该发布返回所有记事本和每个记事本的前5个备注。因此,现在在minimongo中,我们在任何时候都有(5 x(记事本数量))的笔记。
所以最初的负载有点重,但我希望在那之后,在记事本之间导航会快得多。
因此,在加载时,我订阅了myInfo
,它返回用户的记事本和每个记事本的5个笔记。
然后,当您实际单击记事本时,我订阅了myNotepadInfo
,它也会返回记事本的前5个注释。由于初始订阅已经检索到此信息,因此minimongo中的任何文档都不会实际更改。但我仍然想订阅myNotepadInfo
,因为我有一个加载更多注释的机制,它依赖于模板中的订阅。
因此,我的应用程序完全处理了这些更改,但我不确定幕后发生了什么,以及这种方法是否真的有助于提高性能。我没有注意到更改后notepads的加载方式有什么具体的区别。
所以基本上我有第二个订阅,它与最初的订阅重叠。
在我看来,由于第二次订阅与第一次订阅重叠,它必须向客户端传输较少的文档,所以它应该更快?
发布于 2016-10-12 06:51:21
这方面的两个关键问题是(1)您向客户端发送了多少数据?;(2)您预计会有多少用户?
第二点需要一些解释。Meteor当前(2016)发布订阅架构中的一个关键组件是在服务器上注册和跟踪客户端订阅。每个不能重用的额外订阅(即不复制另一个订阅)都会增加应用程序的CPU需求。在这里,听起来好像每个用户都“拥有”一个记事本(尽管事实可能并非如此)。如果是这样的话,这将意味着低订阅重用--每个用户都需要一个独立的订阅来接收他/她的记事本,因为它们不能在用户之间重用。因此,每个用户订阅两个记事本将有效地将应用程序的CPU占用部分加倍,这是由于订阅了记事本。
这不一定是一件坏事。如果您的应用程序是为管理、内部服务或简单地减少用户数量而设计的,那么它可能不会产生明显的差异。对于一个希望/期望高用户数量的面向消费者的应用程序来说,这将是一个糟糕的选择。
Kadira写了一篇关于观察者重用is here的好文章,我也推荐他们(付费)的防弹流星文章。
最后,您可以查看一些旨在改善这些问题的Kadira工具,Subs Manager和Fast Render。不过,您应该检查它们是否仍在积极维护中--我没有。
https://stackoverflow.com/questions/39984886
复制相似问题