2

これが私の問題です。

ユーザーがメモ帳にメモを保存できるアプリがあります。

現在、ユーザーがメモ帳をクリックすると、そのメモ帳の最初の 5 つのメモを返すパブリケーションを購読しています。

したがって、ユーザーが新しいメモ帳に移動するたびに、新しいサブスクリプションが設定され、そのメモ帳の 5 つのメモが minimongo になります。したがって、ミニモンゴは一度に 5 つのノートしかノート コレクションに持ちません。

ユーザー エクスペリエンスを向上させるために、パブリケーションを変更したので、アプリ全体の初期ロード時に、すべてのメモ帳と各メモ帳の最初の 5 つのメモを返すパブリケーションをサブスクライブします。これで、minimongo では、常に (5 x (メモ帳の数)) の数のメモが作成されます。

そのため、最初の負荷は少し重くなりますが、その後、メモ帳間の移動がはるかに高速になることを願っています.

したがって、ロード時にサブスクライブするmyInfoと、ユーザーのメモ帳が返され、メモ帳ごとに 5 つのメモが作成されます。

次に、実際にメモ帳をクリックすると、私は を購読しmyNotepadInfoます。これは、メモ帳の最初の 5 つのメモも返します。最初のサブスクリプションで既にこの情報を取得しているため、実際には minimongo のドキュメントは変更されません。myNotepadInfoしかし、テンプレートのサブスクリプションに依存するもっと多くのノートをロードするメカニズムがあるため、まだサブスクライブしたいと思っています。

したがって、私のアプリはこれらの変更に完全に対応していますが、内部で何が起こっているのか、この方法が実際にパフォーマンスを向上させているのかはわかりません。変更後のメモ帳の読み込み方法に具体的な違いは見られません。

したがって、基本的に、最初のサブスクリプションと重複する2番目のサブスクリプションがあります。

私には、2 番目のサブスクリプションが最初のサブスクリプションと重複しているため、クライアントに転送するドキュメントが少なくて済むように思えます。

4

1 に答える 1

0

これに関する 2 つの重要な質問は、(1) クライアントに送信するデータの量はどれくらいか? (2) 何人のユーザーを期待していますか?

2 番目の点については、説明が必要です。Meteor の現在 (2016 年) の pub サブ アーキテクチャの重要なコンポーネントは、クライアント サブスクリプションがサーバーに登録され、追跡されることです。再利用できない追加のサブスクリプション (つまり、別のサブスクリプションを複製しない) ごとに、アプリの CPU 要件が増加します。ここでは、各ユーザーがメモ帳を「所有」しているように見えます (そうではないかもしれませんが)。その場合、サブスクリプションの再利用率が低いことを意味します。メモ帳はユーザー間で再利用できないため、各ユーザーは自分のメモ帳を受け取るために個別のサブスクリプションが必要になります。したがって、ユーザーごとに 2 つのメモ帳サブスクリプションは、メモ帳サブスクリプションによるアプリの CPU フットプリントの部分を効果的に 2 倍にします。

それは必ずしも悪いことではありません。アプリが管理用、社内サービス用、または単に少数のユーザー向けに設計されている場合、それほど大きな違いはないかもしれません。高いユーザー数を期待/期待する消費者向けアプリの場合、これは悪い選択です。

オブザーバーの再利用に関する Kadira の優れた記事はこちらです。また、(有料の) Bulletproof Meteor の記事もお勧めします。

最後に、これらの問題を改善するための Kadira ツール、Subs ManagerおよびFast Renderを確認してください。ただし、それらがまだ積極的にメンテナンスされているかどうかを確認する必要があります-私はしていません。

于 2016-10-11T22:51:21.383 に答える