App Engineは、より明るい未来とリソースを計算するための新しい方法論に向けて本格的です。 パニックとカオスはAEの下で開発者の仲間入りをしました-あまりにも多くが厳重に守られています（または、会社は何が起こるかを本当に知りません）。 しかし、今日は、ブロブストアが無料のクォータに含まれるかどうか、またはブロブストアへのアクセスに単独で料金を支払う必要があるかどうかについては説明しません。 新しい価格が高すぎる場合の行き先については説明しません。また、Googleが新しいトラックへの移行を緩和しようとしている50ドルの「景品」については説明しません（特に、この良いニュースはすべてのアプリケーション管理者に送信されたため）。
今日はアプリケーションの最適化に焦点を当てます。 プロセッサ時間とメモリの最小消費のためにアプリケーションをすでに最適化しましたか？ それを忘れて、今では二次的であり、あなたの血液は他の基準によって除去されます。
エントリー。
新しい価格への切り替えプロセスの一環として、アプリケーション使用レポートに含まれるリソースのセットを更新しました。 プロセッサ時間を断念し、インスタンスの作業時間数（フロントエンドとバックエンド）、API呼び出しの数、保存されているデータの量、トラフィックを考慮したシステムに移行します。 詳細はFAQをご覧ください 。
新しい価格設定モデルを開始する前に、比較アカウントをリリースしたため、コストにどのように影響するかを確認できます。 価格の変更が有効になる前にアプリケーションの最適化を開始し、最適化がアカウントにどのように影響するかを確認できます。
この記事では、新しい使用状況レポートの解釈方法と、リソースの管理に使用できるいくつかの戦略と、それらがアプリケーションのパフォーマンスにどのように影響するかを示します。
古いレポートと新しいレポートを調査します。
毎日の使用状況レポートは、
_https://appengine.google.com/billing/history?&app_id=$APP_ID
ある[請求履歴]ページのコントロールパネルにあります。 いずれかのレポートの横にある[+]アイコンをクリックすると、1日の詳細が展開され、新しいリソースと古いリソースを確認できます。 アプリケーションの使用状況レポートのプレビューは次のようになります。
アカウントのパラメーターのリストを調べて、それらの意味を説明し、いくつかのリソース管理戦略を提供し、それらがアプリケーションのパフォーマンスにどのように影響するかを説明します。
インスタンスの使用を管理します。
新しいアカウントの最初の2行は、アプリケーションインスタンスの使用に関するものです。 インスタンスについては、ドキュメントをご覧ください。 コントロールパネルのアプリケーションで使用されているインスタンスの数は、
_https://appengine.google.com/instances?&app_id=$APP_ID
または、
_https://appengine.google.com/dashboard?&app_id=$APP_ID
ドロップダウンリストで
_https://appengine.google.com/dashboard?&app_id=$APP_ID
インスタンス]チャートを選択する
_https://appengine.google.com/dashboard?&app_id=$APP_ID
。
スケジューラApp Engine。
App Engineは、スケジューリングアルゴリズムを使用して、アプリケーションがトラフィックを処理するために必要なインスタンスの数を決定します。 アプリケーションが受信した各リクエストに対して、利用可能なインスタンス（アイドル状態または並列haproリクエストを受け入れるインスタンス）にサービスを提供するか、リクエストを待機キューに送信するか、このリクエストの新しいインスタンスを開始するかを決定します。 使用可能なインスタンス、アプリケーションがリクエストに応答する速度（レイテンシ）、リクエストを処理する前に新しいインスタンスを開始して初期化するのにかかる時間に基づいて決定します。 ほとんどの場合、新しいインスタンスを開始することでリクエストをより速く処理できると考えられる場合、新しいインスタンスを開始します。
もちろん、アプリケーショントラフィックには一貫性がないため、スケジューラはアプリケーションのアイドルインスタンスの数を監視し続けます。 これらのインスタンスは、ユーザーへの顕著な遅延なしにトラフィックの急増に対応するのに役立ちます。 スケジューラーは、アプリケーションのアイドルインスタンスが多すぎると判断した場合、リソースを撤回し、インスタンスの1つを停止します。
使用されるインスタンスの数を減らすための戦略。
レイテンシーの削減。
アプリケーションの遅延は、アプリケーションのサービスに必要なインスタンスの数に大きな影響を与えます。 したがって、遅延を減らすと、必要なインスタンスの数に大きく影響する可能性があります。 待ち時間を短縮する手順のリストは次のとおりです。
- 頻繁に使用される共有データをさらにキャッシュします。 つまり、Memcacheを使用します。 アプリケーションにcache-controlヘッダーも設定すると、サーバーとブラウザーのキャッシュ効率を大幅に向上させることができます。 数秒間のキャッシングでも、アプリケーションの効率を大幅に向上させることができます。 Pythonアプリケーションもランタイムキャッシュを使用する必要があります 。
- Memcacheをより効率的に使用します。 一連のシングルの代わりにバッチ呼び出しを使用します。
- クエリ以外のアクティビティにはタスクを使用します。 アプリケーションがリクエスト提供ユーザーの外部で実行可能なアクションを実行する場合、タスクに送信します。 実行がリクエストを完了するのを待つのではなく、これらのアクションをタスクキューに送信することで、ユーザーの顕著な遅延を大幅に減らすことができます。 タスクキューを使用すると、実行速度を大幅に制御でき、負荷をより均等に分散できます。
- データウェアハウスをより効率的に使用します。 以下の詳細を掘り下げます。
- URLフェッチリクエストを並行して送信します。
- HTTPセッションをJavaで非同期に記録します。 HTTPセッションでは、
<async-session-persistence enabled="true"/>
をappengine-web.xmlファイルに追加することにより、アプリケーションがデータストアに非同期でセッションデータを書き込むように設定できます。 セッションデータは常にmemcacheに同期的に書き込まれ、リクエストがmemcacheにないデータを取得しようとすると、リクエストはデータストアに送信されますが、データストアにはまだ最新の更新がない可能性があります。 これは、アプリケーションが期限切れのセッションデータを受信するリスクはほとんどないことを意味しますが、ほとんどのアプリケーションでは、速度の向上はこのリスクをはるかに上回ります。
スケジューラを手動で調整します。
コントロールパネルの[アプリケーションの設定]ページには、スケジューラがアプリケーションインスタンスを管理するために使用するいくつかの変数を設定するのに役立つ2つのスライダーがあります。 以下に、パフォーマンスとリソース使用の妥協点を見つけるためにそれらを使用する方法の簡単な説明を示します。
- アイドルインスタンスの最大数を減らします。 最大アイドルインスタンスを設定すると、アプリケーションのアイドルインスタンスの最大数を制御できます。 この制限を設定すると、App Engineはこの制限を超えてアイドル状態のインスタンスを停止し、追加のクォータを消費したり、追加のコストが発生したりしないようにします。 ただし、アイドルインスタンスが少ないことは、トラフィックの急増時にApp Engineスケジューラが新しいインスタンスを開始する必要があることを意味します。これにより、ユーザーに気付く待ち時間が長くなる可能性があります。
- 最小待機遅延を増やします。 Min Pending Latencyを増やすと、指定した時間を超えてリクエストがキューに入れられるまで、新しいインスタンスを開始しないようApp Engineスケジューラーに指示します。 すべてのインスタンスがビジーの場合、ユーザーにサービスを提供するリクエストは、このしきい値に達するまでキューで待機する必要があります。 このパラメーターに大きな値を設定すると、実行するインスタンスの数が少なくなりますが、負荷の増加中にユーザーに大幅な遅延が発生する可能性があります。
Javaで同時要求を有効にします。
リリース1.4.3では 、アプリケーションのインスタンスがJavaで複数の同時リクエストを処理する機能を導入しました。 このオプションを有効にすると、必要なインスタンスの数が減りますが、アプリケーションが正しく機能するには、アプリケーションがスレッドセーフである必要があります。 Javaのドキュメントで同時クエリの詳細を読むことができます 。
注 ：Pythonのマルチスレッドは、作業計画で利用可能なPython 2.7のリリースまで利用できません。 Python 2.7では、マルチスレッドインスタンスはより多くのリクエストを処理でき、API応答のブロックを待機しているときにアイドル状態の場合、インスタンス時間のクォータを消費しません。 Pythonは現在、一度に1つのインスタンスに対して複数のリクエストを処理する機能をサポートしておらず、すべての開発者が同時リクエストに適応できるようにするため、2011年11月20日までフロントエンドインスタンスの稼働時間を50％割引します。Python2.7は終了しましたテスト。
アプリケーションストレージ管理。
App Engineは、データウェアハウス内のオブジェクトのサイズ、データを提供するために必要なインデックスのサイズ、およびブロブストア内のデータの量に基づいてストレージコストを計算します。
インデックスに必要以上のデータが含まれているかどうかを確認するために実行できる手順は次のとおりです。
- Get Indexes関数（ Java 、 Python ）を使用して、アプリケーションに設定されているインデックスを確認します。 アプリケーションに不要なインデックスを削除すると、データストレージが節約され、オブジェクトの記録コストが削減されます。 また、コントロールパネルの
_https://appengine.google.com/datastore/indexes?&app_id=$APP_ID
、作業中のアプリケーションインデックスを確認できます。 - データモデルを設計するときは、インデックスの総数を減らすクエリを作成できるかどうかを確認してください。 App Engineがインデックスを作成する方法の詳細については、 クエリとインデックスのドキュメントをご覧ください。
データストアを使用して管理します。
新しいモデルでは、（現在使用されているCPUリソースの代わりに）データストアで実行される操作の数を考慮します。 データストアリソースの消費を削減し、データストアリクエストの待機時間を短縮できるいくつかの戦略：
- データモデリングを再構成して、クエリをより効率的で安価なキーフェッチに置き換えます。
- 可能な場合は、すべてのオブジェクトを照会する代わりに、キーのみの照会を使用してください。
- 待ち時間を短縮するには、複数の単一の
get()
要求を1つのバッチget()
に置き換えます。 - ページ分割するには、オフセットの代わりにデータストアポインターを使用します。
- 非同期データストアAPI（ Java 、 Python ）を使用した並列複数データストアクエリ。
トラフィック管理。
発信トラフィックを削減する主な方法は、応答で適切な
Cache-Control
ヘッダーを設定し、静的ファイル（ Java 、 Python ）の妥当な有効期限を設定できる場合です 。
Cache-Control: public
ヘッダーを使用すると、プロキシとユーザーブラウザーは割り当てられた時間の応答をキャッシュできます。
着信トラフィックは、ユーザーがアプリケーションに送信するデータ量であるため、制御がより困難です。 ただし、これはDoS保護サービス（ Java 、 Python ）に言及する良い機会です 。これにより、不要なIPからのトラフィックをブロックできます。
他のリソースの管理。
レポートの最後の値は、Email、XMPP、およびChannel APIの使用です。 これらのAPIについては、それらを効果的に使用することを確認するのが最善です。 APIの使用をテストする最良の方法の1つは、Appstats（ Python 、 Java ）を使用して、アプリケーションが不要な呼び出しを行わないようにすることです。 また、エラーレベルを確認し、可能性のある不正な呼び出しを探すことを常に確認することをお勧めします。 場合によっては、そのような呼び出しを事前にキャッチすることが可能です。