2

高速でスケーラブルな Web アプリケーションを作成する方法についてしばらく考えた結果、Google App Engine、Python+Django、および app-engine-patch を組み合わせることにほぼ決定しました。しかし、 app-engine-patch FAQでコメントに出くわしましたDjango のインスタンスを起動するのに数秒 (FAQ によると 1 ～ 4) かかる場合があります。リクエストからリクエストへの永続性がある場合は問題にならないかもしれませんが、持続的なトラフィックがない場合、Django インスタンスは数秒でシャットダウンされるようです。システムが 1 秒おきに呼び出されない場合、着信要求が許可されるまでに数秒 (!) かかります。これは受け入れがたい。簡単な修正として (醜いことはわかっています)、フレームワークを維持するためだけに、フレームワークに対して毎秒ダミーのリクエストを行う外部マシンを用意することを考えていました。

これに同意しますか？他のアプローチはありますか？

私が持っているもう1つの疑問は、1つのnサーバーからn + 1にジャンプするのに十分なトラフィックがある場合にどうなるかということです.新しいDjangoインスタンスを開始する必要があるため、そのリクエストが許可されるまでに数秒かかりますか? または Google のインフラストラクチャはこのように機能しませんか? これについては私の無知を告白します。問題。

ヘルプ！

4

5 に答える 5

3

はい、長い起動時間は、多くのコードを含むフレームワークを使用する際の警告です。現在、軽量のフレームワーク (組み込みの webapp フレームワークなど) を使用する以外に、それらを回避する方法はありません。

アプリのポーリングはお勧めしません。アプリは複数のインスタンスで実行されるため、クォータを使い果たします。また、実際のユーザー リクエストがポーリング リクエストと同じインスタンスに到達することを保証するものではありません。

幸いなことに、簡単な解決策があります。人気を得ることです。アプリの人気が高いほど、インスタンスを再起動する必要が少なくなり、影響を受けるユーザーの割合が少なくなります。

于 2009-09-26T21:06:48.683 に答える
1

彼らはまた、FAQ で、Django の圧縮バージョンを使用するとロード時間が短縮されると述べていますが、それでも長いかもしれないと推測しています。元の質問については、Google がリクエストを多くのマシンなどに分散する可能性があるため、アプリをポーリングしても問題が解決しない可能性が高いため、アプリをポーリングすることはおそらく良い考えではないという意見に同意します。

于 2010-01-11T02:54:04.977 に答える
1

私はあなたがやろうとしていることを尊重しますが、これは時期尚早の最適化のように思えます。あなたが議論しているpy + djangoパッチは、Googleが「本物の」djangoにアップグレードするまで推奨されているので、それほど悪いとは思えません。あなたが話していることのパフォーマンスをテストすることもそれほど難しいことではないので、最終的な決定を下す前に、最初にそれを行い、いくつかのメトリクスを実行することをお勧めします. そうすれば、他の誰かが不平を言い始めたときに、それを裏付ける数学が得られます;)

于 2009-09-26T19:38:33.587 に答える
0

松尾隆の比較を参照してください。基本的に、ほとんど何もしない最も単純な app-engine-patch の場合、webapp+Django テンプレートの約 350 ミリ秒に対して、彼は約 1 秒と主張しています。

私たちのアプリでは 1 秒よりも長いように感じますが、Takashi は考えられる最も単純なアプリを試してみました。

于 2009-12-31T14:40:06.380 に答える
0

また、組み込みの Django (.97 または 1.0) を使用すると、読み込みの問題が少なくなるように思えます (ただし、間違っている場合はニックがここで修正できます)。論理的に言えば、組み込みのライブラリを全員のメモリに保持するか、キャッシュされたコードをインスタンス間で共有すると思います。しかし、よくわかりません。

于 2009-09-27T11:53:19.240 に答える