【发布时间】:2013-12-07 00:55:14
【问题描述】:
我有一个非常大的集合(约 40000 个文档,包含约 20-25 个字段,包括包含约 500 个项目的数组字段)和约 2000 个订阅者(他们现在只是机器人)。
因此,当用户订阅整个集合(不包括服务器发布中的某些字段)并将 Collection.find 与自定义过滤器、排序和顺序一起使用时,客户端的工作真的很辛苦
我尝试使用带有选项的发布:即客户端定义的过滤器等。但在这种情况下,我在服务器上有太多内存泄漏,几个小时后史诗般的失败:)。
任何人都可以为这种集合提供一些发布-订阅模式吗?我不要求明确的解决方案,而是一些有用的想法
谢谢
【问题讨论】:
-
您所说的内存泄漏......知道它们可能来自哪里吗?您说,您正在使用带有客户端定义过滤器的订阅。您确定当用户更改过滤器时您的订阅会被取消吗?
-
是的,所有订阅都按预期进行。但是我想当订阅的选项发生变化时,垃圾收集器的工作量很大。如果我有 2000 个具有不同选项(即过滤器)的用户,那就像我有 2000 个不同的订阅
-
不错的实验顺便说一句。如果您是第一批在如此重的负载下测试 Meteor 的人之一,我不会感到惊讶。
-
哈!现在我害怕流星的生产。
-
您能否更准确地定义您在此处描述的测试用例。我对您正在运行的服务器的数量/类型以及每台服务器同时连接的客户端数量等细节感兴趣。此外,典型的客户端需要从服务器获取多少数据?你说的“几个小时后”到底是什么意思? :)
标签: meteor