Googleは多くのすばらしいことをしました-検索、スパムのないメール...
IT業界ではしばらくの間、AppEngineについて十分な騒音がありましたが、新しいプロジェクトで彼と一緒に仕事をしようと決めました。
最高の互換性と速度を得るために、GoogleフレームワークでPythonを選択しました。 私はパフォーマンステストから始めましたが、結果は... ややがっかり。
| テスト | 1秒あたりのリクエスト |
| 「Hello world」を印刷 | 260 |
| 1データストアからの読み取り、データストアへの書き込み | 38 |
| 1データストアからの読み取り | 60 |
| データストアからの10の読み取り値、1エントリ | 20 |
| memcachedから1回読み取り、memcachedに1回書き込み | 80 |
| 1 memcachedからの読み取り | 120 |
| 通常のLAMPアプリケーション、6つのSQLクエリ、 http：//3.14.by/ | Atom 330サーバーでは240
7ドルの共有ホスティングで198 |
このテストは、同じ大陸にある2つの異なるサーバーからの20の並列リクエストで実行されました。数値は、実行の7秒間の平均です（後で10分間の空洞化）。 「ヘイ！ 結果はそれほど悪くありません。私の[ここにURLを挿入]は1秒間に2つのリクエストしか処理できないため、20-38でもすでに悪くはありません。」 これは数行の最も単純なアプリケーションであると答えます。このアプリケーションでは、1ページあたり5〜25個のデータの要求が必要になります。 さて、毎秒100リクエストを表示しない古典的なLAMP Webアプリケーションは、ダンプに直接送信する必要があります。
さらに、テスト「10読み取り値1レコード「エラー」エラー：サーバーエラー「10以上の並列クエリが使用された場合、内部エラーが発生しました（これらのデータストアエンティティの競合が多すぎます。再試行してください）」-予期しない例外の例の1つ突然です。
拡張性
ある時点で、GAEがアプリケーションを複数のサーバーに配布すると予想していました（少なくとも理論上はそうだったはずです）。 ただし、10分間のストレステストを行い、1日の割り当ての10％をCPUに費やした後、速度はまったく同じままでした。 おそらく、GAEはアプリケーションを高速にスケーリングしません。
ソースコード
非常に簡単：
google.appengine.ext import dbから
クラスカウンター（db.Model）：
nick = db.StringProperty（）
カウント= db.IntegerProperty（）
res = Counter.gql（ "WHERE nick = 'test3'"）
'Content-Type：text / html'を印刷します
印刷する ''
print '<html> <body> <h1>これはデータストアパフォーマンステストです</ h1>'
print '<h2>カウンタを読み取り、データストアの値をインクリメントします</ h2>'
解像度のvの場合：
v.count = v.count + 1
「新しいカウンター値：」、v.countを印刷します
＃v.put（）
'</ body> </ html>'を印刷します
アプリケーションはここにアップロードされます： http : //mafiazone-dev.appspot.com/ 。
一般に、Googleが約束するとおり、すべてが実際に機能します。速度は規模に依存せず、小規模ではゆっくり、大規模ではゆっくりです:-) Datastoreまたは複数のMemcachedでの作業を必要とする何かに対する単一の要求でも多くの時間がかかります。 まあ、ページごとにいくつかのリクエストを行う必要がある場合、タイムアウトによって例外が表示される可能性が劇的に増加します。
（私のホームページのような）通常のLAMPアプリケーションは、1日あたり1万件のヒットを簡単に処理できます。さらに厳密な最適化の後、3万件（ピーク時8〜10時間で1秒あたり500件のヒット）に対応できます。 この負荷の少なくとも10％を必要とするプロジェクトはいくつありますか？ しかし、処理できなかった、または処理できなかった例外のために、これらのリクエストの0.01％が失敗した場合はどうでしょうか？
私の意見では、問題の一般的なリスト
Google AppEngineを使用する場合は、次のことに注意してください。
- Datastoreへのアピールは、わずかなチャンスで誤って落ちる可能性があります。 Googleは、この可能性は0.4％から0.1に低下したが、まだ残っていると言います。 データストアは古典的なデータベースとして設計されていません-予想される時間に対する答えは保証されていません。 そして、可能性のあるすべての例外を処理することはできません。 これにはすべてプロセッサー時間が必要ですが、制限があります。
- Memcachedは、慣れているmemcachedではありません。 ここでは、非常に低速です（通常は数万回ではなく、1秒あたり数十回の操作）。
- 静的データを保存する場所を見つける必要があります。 GAEから大きなファイルを配布することはできません。また、非常に高速で非常に高価ではありません。
- URLFetchの信頼性が十分でないというレビューがあります。 私はこれが時間内に修正されると思う:-)
- データセンターを選択することはできません。 たとえば、ヨーロッパに住んでいて、GAEが米国でアプリケーションを起動した場合、ユーザーはすべてがやや遅いと感じ、アプリケーションをヨーロッパに移動することはできません。 それ自体は転送されますが、不明な場合は転送されます。 私のベンチマークをすべて行った後、私のものは決して生き残れませんでした。
- Googleは無制限の数のリクエストを処理できますが、各リクエストは少なくとも100〜200ミリ秒であり、アプリケーションは「飛ぶ」ことはありません。 そして、新しい予期しない例外を処理するために追加のコードを書く必要があることを忘れないでください。
- Googleは、数百万のリクエストに対して十分な無料の制限があることを保証します。 ただし、私の最も単純な例では、15,000リクエストに0.65 CPU時間を費やしました。 1日あたりわずか15万件のヒット。 したがって、有料サービスはあなたが想像するよりもいくらか高価です。 おそらく、これらの数百万は100％の静的ページでのみ達成可能です。
- Googleは、オープンソースソリューションとは何かについて多くを語ることができますが、そうではありません。 主要なテクノロジーは閉じられており、テストSDKサーバーは意図的にスーパーブレーキをかけたようです（Core2Duo 3.6Ghzでは1秒あたり2リクエストのみ）。 そのため、競合他社は、サービスに我慢するか、0からすべてを書き換えます。
だから私はGAEで異なって見たいです：
- より決定的な動作。 制限を超えた場合-例外をスローするよりもメールで警告を受け取りたいのですが、処理できない可能性があります。
- データストアとMemcachedのパフォーマンスが大幅に向上しました。 Memcachedはおそらくここで一般的であり、リクエストが殺到しているので...
- データセンターの選択
- クラスター対応API。 「ストレージの初期化」および「ストレージの解放」というイベントを使用して、ローカルサーバーに非常に高速なメモリを少し置いておくといいでしょう。
もう少し考え
しばらく前、私は非常にクールなテクノロジーを使用していました。すべてが冗長で信頼性が高く、「クラウド」で便利なAPIでしたが、フォーラムページの描画には4プロセッサーサーバーで4秒かかりました。 それは完全なたわごとだった。 テクノロジの速度が低下したり、ユーザーがそれに慣れていない場合、このテクノロジは完全に不要です。 「かっこいい」という理由だけでテクノロジーを使用するのは、どういうわけか馬鹿げています。
Google App Engineを使用できる場所と使用しない場所
GAEは、ピーク負荷のない単純な読み取り専用（つまり、複雑なデータベースロジックのない、小さなデータボリューム）アプリケーションに最適です（つまり、オンザフライでスケーリングできない場合があります）。 ホームページは、サポートコストなしでGAEに完全に配置されます。
これは、画面上に多くのロジック、多くのデータがあり、時々shashdot / habra効果がある複雑なアプリケーションには適していません。 Google AppEngineは、1秒あたり数百のリクエストという予期しないピークを処理できない場合があります。
おわりに
これはすべて、ゴーグルのプログラマーとアーキテクトが愚かなことを意味しますか？ ：クレイジー：まったくそうではありません。実際、そのような条件下では、より良い達成は困難です。 クラスタ用に特別に調整されていないアプリケーションの無制限のスケーラビリティを実現することは本当に困難です。 その結果、ほとんどのアプリケーションはGAEで適切に動作できなくなります。
しかし、アプリケーションがGAEの機能と制限にうまく適合し、パフォーマンスとエラーの可能性に満足している場合、これが最適なソリューションになると思います。
ここにあります 。 そしてここで -英語で。