6

GAEでの請求はすべて、インスタンス時間（ "IH"）、つまり一定期間実行されているサーバーインスタンスの数に要約されると私は理解しています。ただし、 IHに加えて、1日を通して使用する必要のあるクォータとリソース制限があるため（クォータは24時間ごとに補充されるため）、明らかにそれほど単純ではありません。

私は最初のGWT/GAEアプリを設計している最中であり、多くの記事（そのうちのいくつかは以下に引用されています）に出くわしました。 Googleでの請求と運用コストを最小限に抑えます。

ある例では、開発者はGAEアプリに一連の最適化を実装しました。これにより、同じアプリが最終的に「無料」の割り当てとリソースの請求しきい値を下回ったため、同じアプリが1日あたり7ドル（月額220ドルまで）から0ドルに下がりました。 。

GAEに非常に慣れていないので、アプリのアーキテクチャ/設計に事前に組み込むことができる一連の原則または実践があるかどうか疑問に思っています。これは、実装された関数型コードに細流化され、GAEにデプロイされると、アプリを引き起こします。可能な限り効率的に（金銭的に言えば）実行する。

これまでに私が行ったいくつかの控除は次のとおりです。

  • キャッシュを最大化し、データストアのヒットを最小化します
  • できるだけ多くの非同期リクエスト処理をバックエンドインスタンスにプッシュするようにしてください
  • 同じインスタンスが同時に複数のリクエストを処理できるように、同時HTTPリクエスト処理を有効にします

だから私の質問：私が間違ったこれらの一般化のいずれかがありますか？もしそうなら、なぜ（またはそれらは条件付きであり、ある場合には当てはまりますが他の場合には当てはまらない）？ここで重要なものが欠けていますか？たとえば、どのコードがバックエンドインスタンス（リソースの制約が少し緩い）に属しているかを判断し、どのような種類のGAE固有のプロファイリングツール（AppStats、SpeedTracerなど）を使用してボトルネックなどを確認するか。

また、いくつかの引用記事：

4

2 に答える 2

2

経験に基づいて、App Engineの最適化のための戦略の膨大なリストがあり、その適用性はアプリの性質によって異なります。これが私が知っているいくつかのヒントです：

  • 比較的静的なコンテンツを大量に提供するアプリの場合、（まだ文書化されていない）エッジキャッシングを有効にすることは、毎週の請求に祝福をもたらす可能性があります。

  • 同時リクエスト/スレッドセーフが有効になっている場合でも、スケジューラが新しいインスタンスを起動することを決定する前に、各フロントエンドインスタンスは8 （Pythonの場合）から10（Java、Go）の同時着信リクエストしか処理できませんでした。

  • 上記の制限に対抗するために、フロントエンドインスタンスに送信されるユーザー向けのリクエストの応答時間を最大100ミリ秒に短縮することを推奨するGoogle I/Oビデオがあると思います。

  • 上記の戦略に合わせて、大量の処理またはデータストアI / Oを必要とするタスクがある場合は、そのタスクをプッシュタスクキューにオフロードし、すぐに要求に応答します。タスクキューのターゲットを指定できますが、この目的のためにバックエンドである必要はありません。フロントエンドインスタンスは十分に優れており、無限のスケーラビリティを提供します。

  • 上記の戦略を使用しても、処理またはI / Oの結果をユーザーに提供する必要がある場合は、チャネルAPIまたはその他のメッセージングサービスを使用して、結果を非同期で送り返します。

  • タスクキューは、アプリのワークロードを分散するためのすばらしい機能です。その動作を詳細にカスタマイズすることができ、アプリが適切にスケーリングされるようにするために非常に役立ちます。プッシュキューとプルキューの両方を使用して、インスタンス間で双方向通信を行うこともできます。

後でポイントを追加します。

于 2012-08-23T06:22:39.740 に答える
0

ほとんどの場合、コストの最適化はアプリに固有のものになります。一般的な原則について質問しているので、それらは主にCPUとデータストアに適用されます。

CPU：

停止したCPUの支払いに注意してください。長時間の操作（遅いデータストアリクエストやURLフェッチなど）でCPUが停止した場合、App Engineは別のインスタンスを起動し、コストを押し上げる可能性があります。これにはいくつかの戦略があります-スレッド化、タスクキューを有効にします。バックエンドに非同期リクエストを配置することについて話したとき、それはこの問題も解決することだと思います。これを処理する方法は複数あります。

データストア：

  1. インデックスを慎重に管理してください。インデックス作成は、コストに大きく影響します。

  2. 必要なリクエストの数を最小限に抑えるために、データストアを慎重に設計してください。

  3. 非正規化。非正規化は、NoSQLデータストアのかなり標準的な手順です。基本的に、必要に応じて重複データを複数のエンティティに保存することを意味します。これにより、リクエストごとに支払うため、App Engineで$を節約できますが、返すエンティティのサイズには支払いません。たとえば、ウィジェットを販売するストアがある場合、単一のストアのウィジェットすべての要約バージョンをストアエンティティ内に保存することができます（1MBのエンティティ制限内に収まることが期待される場合）。そうすれば、ストアのページを表示するときに、ストアエンティティとすべてのウィジェットエンティティではなく、1つのストアエンティティのみをフェッチします。同様に、ウィジェットの数をカウントする必要がある場合は、クエリを発行してカウントを取得するよりも、ストアエンティティ内にその値を含める方が適切です。

キャッシング：

キャッシングにより、CPU側とデータストア側の両方でコストを節約できます。Google IOからのかなり良いビデオがあります： https ：//developers.google.com/events/io/sessions/gooio2012/310/

于 2012-08-23T15:38:10.853 に答える