基于这个答案,看起来流星服务器为每个连接的客户端保留了缓存的内存中副本.我的理解是它被用来避免在处理客户端上的重叠订阅时发送多个数据副本.
链接答案的相关部分(重点是我的):
合并框:合并框的作用是将所有客户端的活动发布函数的结果(添加,更改和删除的调用)组合到单个数据流中.每个连接的客户端都有一个合并框.它包含客户端的minimongo缓存的完整副本.
假设在当前版本的流星中答案仍然准确,那么随着用户数量的增加,这不会在服务器上造成巨大的内存浪费吗？
作为一个袖手旁观的计算,如果一个应用程序每个客户端大约有100kB缓存,那么10,000个并发用户将在服务器上消耗1GB内存,而100,000个用户则高达10GB!即使每个客户端都在查看几乎相同的数据,情况也是如此.应用程序使用比每个客户端更多的数据似乎是合理的,这将进一步加剧问题.
当前版本的Meteor中是否存在此问题？如果是这样,可以使用哪些技术来限制服务器管理所有客户端订阅所需的内存量？
看看Arunoda在他的meteorhacks.com博客上的这篇文章:http://meteorhacks.com/making-meteor-500-faster-with-smart-collections.html
其中谈到了他的智能收藏页面:http:
//meteorhacks.com/introducing-smart-collections.html
他创建了一个替代的Collection堆栈,它已经成功实现了速度,效率(内存和CPU)和可伸缩性的目标(您可以在帖子中看到一个图形比较).不可否认,在他的测试中,RAM的使用对于两种Collection类型都是疏忽的,尽管他在那里实现的方式应该与你提到的用例类型有非常明显的区别.
此外,您还可以在这个职位上的流星核看到:
https://groups.google.com/d/msg/meteor-core/jG1KLObX1bM/39aP4kxqWZUJ
的流星开发人员都知道他的工作,并在实施一些正在合作Meteor本身的改进(但在此之前他的智能套装效果很好).
重要的提示!智能收藏依赖于对Mongo Oplog的访问.如果您在自己的计算机或托管基础架构上运行,这很容易.如果您使用的是基于云的数据库,则此选项可能不可用,或者如果可用,将比较小的包花费更多.