成千上萬的併發用戶的流星服務器端內存使用

Question

基於this answer，它看起來像流星服務器保持每個連接的客戶端的緩存的內存副本。我的理解是，它被使用是爲了避免在處理客戶端上的重疊訂閱時發送多個數據副本。

鏈接答案的相關部分（重點是我的）：

合併框：合併箱的工作是所有的結果（添加，更改和刪除電話）相結合客戶端的主動發佈功能集成到單個數據流中。每個連接的客戶端有一個合併框。它包含客戶端的minimongo緩存的完整副本。

假設的答案仍然是準確的流星的當前版本，無法將服務器的用戶數量的增長上創造了巨大的浪費內存？

作爲一個非常規的計算，如果一個應用程序的每個客戶端的緩存大約爲100kB，那麼10,000個併發用戶將佔用服務器上的1GB內存，而100,000個用戶的吞吐量高達10GB！即使每個客戶都在查看幾乎相同的數據，情況也是如此。對於一個應用程序使用比每個客戶更多的數據似乎是合理的，這會進一步加劇問題。

目前版本的Meteor中是否存在這個問題？如果是這樣，可以使用哪些技術來限制服務器用來管理所有客戶端訂閱的內存量？

Answer 1

看看這個帖子由Arunoda在他的博客meteorhacks.com：
http://meteorhacks.com/making-meteor-500-faster-with-smart-collections.html

其中談到他聰明集合頁：
http://meteorhacks.com/introducing-smart-collections.html

他創造了一個另類收藏棧成功在它的目標是速度，效率（內存& cpu）和可擴展性（你可以看到一個圖表比較的帖子）。無可否認，在他的測試中，RAM的使用對於兩種Collection類型都是疏忽的，儘管他在那裏實現的方式應該與你提到的用例類型有非常明顯的區別。

此外，您還可以在這個職位上的流星核看到：
https://groups.google.com/d/msg/meteor-core/jG1KLObX1bM/39aP4kxqWZUJ
該流星開發人員都知道他的工作，並在實施一些改進成流星本身（但在那之前他的智能包裝正在合作工程很棒）。

重要說明！智能收藏依賴於訪問Mongo Oplog。如果您在自己的機器或託管基礎架構上運行，這很容易。如果您使用的是基於雲的數據庫，則此選項可能無法使用，或者如果使用該選項，則會比小型軟件包花費更多。