6

私は数週間前にこの質問をしました。今日、私は実際に標準のDjangoアプリケーションを作成してリリースしました。つまり、 Google CloudSQLによって有効化された完全に機能するリレーショナルDBに裏打ちされた（したがって完全に機能するDjango管理者）。標準のDjangoの方法から逸脱しなければならなかったのは、電子メールを送信することだけでした（GAEの方法で行う必要がありました）。私のセットアップは、、でGAE 1.6.4、Python2.7以下Django 1.3を使用していますapp.yaml：

libraries:
- name: django
  version: "1.3"

ただし、このDjangoアプリがコールドのときに、最初のリクエストの応答時間を改善するための明確な実行可能な手順を提案する必要があります。私はGAEに簡単なwebapp2Webサイトを持っていますが、これはDBにヒットせず、寒いときの応答時間はです1.56s。Djangoは、コールドcount(*)時に2つのクエリ（それぞれ300行未満のテーブルに対する2つのクエリ）でDBにヒットし、応答時間は10.73s！ホームページを奨励していません;）

頭に浮かぶのは、middleware不要なクラスやその他のDjango固有の最適化を削除することです。ただし、GAEの観点からも改善するためのヒントは非常に役立ちます。

NB私はこれがGAEでDjangoに行くことのメリットについての議論になることを望んでいません。私の個人的なDjangoの専門知識と、その結果としての開発の生産性は、他のフレームワークとは対照的に、Djangoの採用にかなりの影響を及ぼしたと言えます。さらに、CloudSQLを使用すると、Djangoコードはほとんど（またはまったく）変更せずに他の場所でも機能するため、GAEから簡単に移行できます（できればそうではありません！）。このようなトピックに関する関連する議論は、こことここにあります。

4

2 に答える 2

2

完全な答えはありませんが、解決策も見つけたいので貢献しています。現在、実行中のcronジョブを使用しています（実際にはcronジョブが必要なので、アプリを存続させるためだけではありません）。

GAE / Python / Django関連のメーリングリストの1つで、すべてのDjangoファイルをロードするのに必要な時間だけがwebappと比較して重要であることが説明されているのを見てきたので、使用しないdjangoコンポーネントをデプロイから削除する必要があります起動時間も改善します。contribフォルダーの特定の部分を削除することで、約3秒短縮できました。app.yamlでそれらを除外します。

私の起動時間はまだ約6秒です（フルアプリ、Django-nonrel、HRD）。私のアプリがもっとシンプルだったときは、以前は4のようでした。

私の疑惑は、Djangoが起動時にすべてのモデルを検証し、処理時間がかなり長いことです。絶対に0モデルのアプリを試してみる時間があれば、何か影響があったかどうか知りたいです。

また、最初の2つのクエリが大きな影響を与えるかどうかについても興味があります。

于 2012-03-30T13:56:54.510 に答える
2

バージョンのアップグレード後や15分間リクエストがない場合など、インスタンスが実行されていない場合、リクエストによってインスタンスの読み込みがトリガーされ、約10秒かかります。だからあなたが見ているものは正常です。

したがって、アプリが15分より長い期間アイドル状態の場合、この動作が表示されます。回避策の1つは、 10分ごとにcronジョブでインスタンスにpingを実行することです（ただし、googleはそれを好まないと思います）。

アップデート：

これを回避するには、GAE管理者の[アプリケーション設定]でminimum[アイドルインスタンス]設定を1に設定します。注：このmin設定は無料アプリでは使用できません。のみmaxです。

于 2012-03-30T13:08:45.900 に答える