2012-03-17 17 views
1

私は、GAEで自分のアプリケーションインスタンスを設定する最良の方法を見つけようとしています。GAEJのメモリ使用量とフロントエンドインスタンスクラスの理解

私はGWT/GAEJでSaasを実行します。私はアプリを毎日集中的に使用する少数のパワーユーザー(毎日数分間アプリを使用する多数のユーザーではなく)を集中的に使用しています。

私はFrontend Instance Classesを最も効率的に使用するように設定する最良の方法を見つけようとしており、最高のユーザーエクスペリエンスを提供しています。

請求を有効にして、インスタンスの起動時に待ち時間を避けるためにアイドル状態のインスタンスを実行する必要があることが判明しました。私はJDOを使用し、各インスタンスの起動時にデータストアのアクセスを初期化するのに時間がかかります。だから私はいくつかのアプリケーションインスタンスを起動し、それらをアイドルモードで実行させます。これは優れたユーザーエクスペリエンスを提供しますが、明らかにアイドル状態のインスタンスには負担がかかります。理想的ではありません。

私はそれをより効率的に行うことができるかどうかを調査します。

これは背景ですが、私の本当の疑問は次のとおりです。 私のインスタンスのメモリ使用量を見ると、定期的に136MBなどと書かれています(約66MBから開始します)。だから私は見つけるためにいくつかのメモリリークがあると思います。しかし、特に私が知りたいのです:

  1. 私はまた、Memcacheのを使用して、おそらくこのメモリは、上記の計算では考慮されていますか?

  2. 私は現在、128MBのメモリサイズを持つF1インスタンスクラスを使用しています。それで、サイズが約136MBに収まるように見える私のインスタンスはどういう意味ですか?彼らはいつもディスクに交換するので、彼らははるかにゆっくり走っていますか?この理由で2つのF1インスタンスの代わりに1つのF2インスタンスを実行する方が良いでしょうか?

  3. 私は2つのアイドルインスタンスがあっても、GAEが新しいインスタンスを開始することが非常に面倒です。これは私が最小待ち時間を非常に高い(7.5秒)に設定しているにもかかわらずです。私は文書で、アイドル状態のインスタンスを使用するときにこの設定がほとんど影響しないことを読んだが、アイドル状態のインスタンスのみを使用して新しいインスタンスを開始することはしないでください(データストアの初期化の問題上記の通り)?

アムIの誤理解何かを(そして多くのインスタンスの時間を経て私にコストを増加させましたか)?何か助けてくれてありがとうございました。

答えて

5

いくつかの注記:

a。 JVMはオンデマンドでメモリを取得しますが、rarely releases it back to OSです。これはメモリリークではありません。

b。保留中のインスタンス数と応答時間を微調整することができます。これにより、実行中のインスタンスの数を制御することができます。詳細はperformance settingsのドキュメントを参照してください。

c。コードの起動が遅く、起動時に長い応答時間を必要としない場合は、warmup requestsを使用します。質問への今の

  1. Memcacheのは、フロントエンドのインスタンスの外部サービスであり、私の知る限りでは、フロントエンドのインスタンス上のオブジェクトを格納しません。したがって、Memcache内のオブジェクトの総数は、フロントエンドインスタンスによって使用されるメモリに反映されるべきではありません。

  2. フロントエンドのインスタンスの実際の基礎となる実装は(少なくともGoogleの外に)知られていないが、私は、彼らがスワップのためのローカルディスクを使用疑います。あなたはいつもF2インスタンスを使用して、それがどのように機能するか見ることができます。新しいインスタンスの

  3. スピンアップは、レイテンシ設定によって指令されます。要求がキューに長時間入れすぎると、新しいインスタンスがスピンアップされます。あなたのインスタンスがスピンアップに時間がかかり過ぎると、悪循環が生じる可能性があります。ウォームアップ要求を使用してみてください。

+0

ピーター、これには多くの感謝。私はウォームアップの要求と一緒に遊ぶだろう、私の答えになる可能性があります。しかし、私は私が持っているインスタンスの経験に非常に不満です。誰かが同様の問題を経験しているのだろうかと思います。私は2つのF1の代わりに1つのF2を実行しようとしました。しかし、実際に私を悩ましているのは、私がどのインスタンスを開始したとしても、今度は3つのアイドルインスタンスがあります。ウォームアップ要求を実装しているかどうかにかかわらず、これは正しくないはずですか? (私がアイドル状態になっている時ではない) – doright

2

は、私はまた、JDO/DataNucleusの初期化が非常に遅いインスタンスへの最初の要求をした問題を抱えていました。私はMemCacheを使用して、データストアにあるほとんどすべてをキャッシュします。 、私のために問題を解決し、すべてをプリロード(今のところ、データが大きくなると、私は重要なことをプリロードすることを変更し、唯一のJDOを初期化することはないので、重要なオブジェクトに触れます)ウォームアップリクエストでその私が、わずか数を持っている1つの常駐インスタンス要求。今では私の1人の居住者と他のオンデマンドインスタンスの使用ははるかに優れています。依然として常駐インスタンスは要求の3分の1しか受け付けていません。

は、私が最初の要求(s)は、後のものよりも時間がかかるとき、スケジューラは、待ち時間の計算の問題を取得すると思います。

+0

こんにちはポール、これはとても面白いです、ありがとう。しかし、私は完全に理解していません。確かにあなたは読み取り専用アプリを持っていないのですか?この場合、インスタンスの数分でDBを更新する必要がある場合は、JDO/DataNucleusヒットが発生する必要がありますか?それで、必然的に遅れるのではないのですか?しかし、私は非常に興味があります。「スケジューラは、最初のリクエストが後のリクエストよりも長くかかるときに、レイテンシ計算に問題が発生すると思います。これまで私には起こっていなかったが、合理的に聞こえる。 – doright

+0

- 私はJDO/DataNucleusの初期化が最初のリクエストのほとんどの時間を取ったと思います。これはウォーミングアップ要求で発生します。これは明らかにレイテンシ平均をカウントしません。 - 要求が新しいインスタンスを開始すると、それにはまだ時間がかかります。私はデフォルト以外のバージョンでのみこれを見ることができます。新しいバージョンが開始されるまで、デフォルトのバージョンでは常に既存のインスタンスにリクエストが送信されることを願っています。 – paul

+0

大丈夫なので、読み取り/書き込みbehaviouについては、何を言っていることは以下の通りです:あなたも、最も要求のためにデータベースをヒットする必要はありませんので、キャッシュに、すべての読み取り要求を置きます。あなたのウォーミングアップリクエストでは、すべての書き込み先に「触れる」ことを確認してください。そうすれば、実際に何かを書くときにはすばやくすべきですが、実際にはあまり遅れずにスケールアップするインスタンスを取得する必要があります。私はこれを試してみる.. – doright