Meteor的DDP协议非常适用于将一小部分数据从服务器同步到基于浏览器的客户端，这本身就限制了处理的数据量。
但是，考虑使用Meteor将大型集合从一个服务器同步到另一个服务器的情况，或者仅使用DDP协议本身将一个MongoDB与另一个服务器同步。
在这种情况下（计算上）DDP的效率如何？它如何扩展到几个客户？性能仅限于带宽还是DDP也会受到一些CPU限制？现在可以通过DDP合理同步的最大数据量是多少？ DDP是否只是错误的做法（参见下面的参考资料）？
一些额外的想法：
另见：
修改：
经过一些实证经验，我必须得出结论，答案是“效率不高”。有关解释，请参阅 https://stackoverflow.com/a/21835534/586086 。
与Meteor开发人员的讨论表明，未来将通过修订DDP和发布 - 订阅API来解决此问题，其中合并框将被删除，客户端将处理合并。这将节省服务器上的CPU /内存，并允许通过线路发送更大的数据集。
答案 0 :(得分：1)
基本上，与客户数量相比，更多的是您向客户发布的内容和方式。如果索引，通常在log2（N）中处理请求，因此即使（在最坏的情况下）整个集合将改变，服务器也很容易重新计算结果集。因此，从服务器端，您可以非常快速地将新结果集发布到客户端（如果它们已经从已经更改的那些更改）。
真正的问题（和常见错误）是在您将所有内容发布到客户端时（如同以前的自动发布一样），因此请明智地制作出版物，以便您只提供客户应该看到的内容。您可以通过创建特定于您的数据使用参数范围的发布来修剪隐藏无用字段的文档或减少要发送到客户端的结果集。
数据反应性（在出版物上绑定的会话参数）也应小心处理，例如，如果您每次在搜索字段中按键时发送请求，您可能会快速超载连接（仍然强烈依赖于你要发布的集合的大小）。我们不得不照顾这个尝试通过meteor建立房地产服务，数据集超过几千兆字节，处理这个问题是非常具有挑战性的，而不会因为数据过载而阻塞管道。
就带宽而言，DDP非常好，因为它确实支持更聪明的条目更新（仅发送字段更改而不是整个文档），移动项目（将）支持（服务器端重新排序）。
另请参阅this excellent answer关于大量藏品的内容，以及在幕后所做的事情。