13

この回答に基づいて、Meteor サーバーは、接続されたクライアントごとにキャッシュのメモリ内コピーを保持しているようです。私の理解では、クライアントで重複するサブスクリプションを処理するときに、データの複数のコピーを送信することを避けるために使用されます。

リンクされた回答の関連部分（強調は私のものです）：

マージ ボックス: マージ ボックスの役割は、クライアントのすべてのアクティブな公開機能の結果 (追加、変更、および削除された呼び出し) を 1 つのデータ ストリームに結合することです。接続されたクライアントごとに1 つのマージ ボックスがあります。クライアントの minimongo キャッシュの完全なコピーを保持します。

その答えが流星の現在のバージョンでも正確であると仮定すると、ユーザーの数が増えるにつれて、サーバー上で膨大な量のメモリが浪費されるのではないでしょうか?

すぐに計算できるように、アプリがクライアントごとに約 100kB のキャッシュを持っている場合、10,000 人の同時ユーザーがサーバーで 1GB のメモリを使い果たし、100,000 人のユーザーはなんと 10GB を消費します! これは、各クライアントがほぼ同一のデータを見ている場合でも当てはまります。アプリがクライアントごとのデータよりもはるかに多くのデータを使用する可能性があり、これは問題をさらに悪化させます。

この問題は現在のバージョンの Meteor に存在しますか? その場合、すべてのクライアント サブスクリプションを管理するためにサーバーが使用する必要があるメモリの量を制限するには、どのような手法を使用できますか?

4

1 に答える 1

5

Arunoda の meteorhacks.com ブログでのこの投稿を
ご覧ください。

彼のスマート コレクション ページについて説明しています:
http://meteorhacks.com/introducing-smart-collections.html

彼は、速度、効率 (メモリと CPU)、およびスケーラビリティ (投稿でグラフ化された比較を見ることができます) の目標に成功した代替コレクション スタックを作成しました。確かに、彼のテストでは、RAM の使用は両方の Collection タイプで無視されていましたが、彼が実装した方法は、あなたが言及したユースケースのタイプと非常に明白な違いがあるはずです。

また、meteor-core に関するこの投稿 (
https://groups.google.com/d/msg/meteor-core/jG1KLObX1bM/39aP4kxqWZUJ)
で、Meteor の開発者が彼の仕事を認識しており、いくつかの実装に協力していることを確認できます。 Meteor 自体の改善 (ただし、それまでは彼のスマート パッケージはうまく機能します)。

重要な注意点！スマート コレクションは、Mongo Oplog へのアクセスに依存しています。独自のマシンまたはホストされたインフラストラクチャで実行している場合、これは簡単です。クラウドベースのデータベースを使用している場合、このオプションは利用できない可能性があります。利用できる場合、小さいパッケージよりもはるかに多くの費用がかかります。

于 2013-08-29T16:51:35.703 に答える