弱点：
1.リクエストごとおよびページごとのCPU_msを制限する
サーバー上で多くの計算を行う要求ごとに、ページはすぐにその制限を使い果たしてアクセスできなくなります。
2. 1日あたりのリクエストの総数の制限
写真やその他のリソースのリクエストを含む、サービスのリクエストは1日に約100万件許可されています。 負荷が高い場合、この数値を達成するのは非常に簡単です。 主な難点は、このリソースを購入できないことです！ 課金がオンになっていても、そのようなリクエストは支払い済みとしてカウントされず、同じ百万件のアプリケーションに到達すると機能しなくなります。 これを回避するには、バナーファイルをAmazon S3ファイルストレージサービスに転送する必要がありました。
3. 1秒あたりのリクエスト数の制限
1秒あたり500を超える要求の強度では、アプリケーションは動作を停止します。 通常の状況では、このような高負荷を達成することは容易ではありません。 Eurovisionガジェットの場合、これは広告バナーが原因で発生しました。 このような問題は、サービスのあるページが人気のあるネットワークリソース（Yahoo！、Slashdot、またはDiggのメインページ）で宣伝されている場合に発生する可能性があります。
ヒントとコツ：
1.すべてをキャッシュ！
ユーザー要求に与えられるものはすべて、memcacheから直接取得する必要があります。 問題を完全に回避するには、スケジュールに従ってキャッシュを更新するcron'yを作成することをお勧めします。 その後、まれなユーザーリクエストでさえ、データベースへのアクセスを必要とせず、追加の計算を実行します。 したがって、弱いサイド番号1を閉じます。
2.静的コンテンツを外部サーバーに最大限転送します。
すべての画像、CSS、Javascriptは、Google Codeにアップロードし、そこから直接ユーザーに提供する方が適切です。 アプリケーションから、ユーザーはキャッシュされたhtmlのみを受け取り、他のすべてのリクエストはそれをロードしなくなります。 これにより、2番目と3番目の弱点がなくなります。
3.不要な場合でも、課金をオンにします。
すでに述べたように、アプリケーションが適切に最適化されている場合、App Engineには十分な無料の制限があります。 5セントが撤回されている間、毎秒最大300件のリクエストを処理するEurovisionガジェットの場合。 そして、それでももちろん、ユーザーの関心が高まったフィナーレの日にだけです。
課金の主なプラス（これを含めることで、App Engineが制限オーバーランの代金を請求できるようにする）は、無料のリソースがまだ残っていることです。 しかし、支払うことができないリソースは、その制限を50倍に増やします！ ユーロビジョンガジェットの課金をオンにした後、1日あたりのリクエスト数の制限が100万から5000万に増加したことに誤って気付きました:)
4.アプリケーションにユーザーデータを保存しないでください。
ユーザー設定とプロファイルをデータベースに保存する場合、ユーザーは頻繁にデータをデータベースに保存するため、負荷が高いとキャッシュをあまりにも頻繁に更新する必要があります。 この方法ではソーシャルネットワークを構築できないことは明らかです。
ユーザーとそのデータを完全に使用するには、Google Friend Connectを使用する必要があります。 非常に簡単に任意のサイトに接続し、Googleアカウント、Yahoo！を介して完全な承認を与えます。 またはopenid。 その後、すべてのユーザーデータはGoogleのサーバーに直接保存され、ソーシャルネットワーク（友好度、コメント、評価など）の観点からアプリケーションに影響を与えることはありません。 一般に、FriendConnectは強力なソーシャル機能をほぼすべてのサイトに簡単に接続できる素晴らしいサービスです。 マイナスの点-これはブラウザに追加の負荷を与え（JavaSciptを使用するため）、初期ロード中にトラフィックをわずかに増加させます。 ただし、将来的には、すべてのスクリプトがキャッシュされます。
要約：
料理ができればApp Engineでほとんど何でもできます:)
さらに、ロードされたサイトであっても、無料の制限を超えることは非常に難しく（正しく作業する場合）、超過した場合でも料金は低くなります。 これは、使用日ごとに料金を支払う必要があるAmazonの同様のサービスを使用するよりもはるかに有益です。
残念ながら、すべてのアプリケーションを残酷に最適化する必要があり、これにより開発時間が長くなります。 原則として、この要件はどのサイトにも当てはまりますが、App Engineの最適化の場合は二重に必要です！..もちろん、これはプロジェクトのタイプに大きく依存します。 サイトにあまり対話性がない場合、作業の速度に関する状況は、最高レベルでキャッシュすることによって保存されます（生成されたhtmlを返す）。 ただし、パフォーマンスの問題は常にそう簡単には解決できません。
PS GoogleはHabréにEvgeny Demchenkoによるこのメモのコピーを投稿しました。GoogleApps.ruの読者だけでなく興味があるかもしれないと思うからです。