ブロブストアに保存されている 1.8Kb ～ 3.6Kb の gzip ファイルを提供する非常に単純なアプリ エンジン アプリケーションがあります。数値ファイル ID から blobkey へのマップがデータストアに保存され、memcache にキャッシュされます。サーブレットの実装は簡単です。数値のファイル ID がリクエストで受信されます。blobkey が memcache/datastore から取得され、標準BlobstoreService.serve(blobKey, resp)が呼び出されて応答が提供されます。予想どおり、アプリのログには、応答のサイズが提供されたブロブストア ファイルのサイズと常に一致することが示されています。
私はいくつかの集中的なボリューム テストを行ってきましたが、これにより、送信帯域幅クォータの使用率が、受信した要求に対して予想されるものの約 2 倍であることが一貫して報告されていることが明らかになりました。クライアントで受信したバイト数を合計して、一度に 10 万件のリクエストを実行してきました。これをアプリ ログと比較し、発信帯域幅クォータの使用率を除いてすべてのバランスをとっています。
上記で説明した単純なアプリケーションで、送信帯域幅クォータの使用率がどのように決定されるかを理解するのに役立ちますか? 私が見逃している、または説明していないものは何ですか? アプリのログに表示される応答サイズの合計と集計されないのはなぜですか?
[2013.03.04 更新: ブロブストアの使用を中止し、ブロブをデータストアに直接保存する方法に戻しました。送信帯域幅の使用率は、予想どおりになりました。2 倍の乗数は、blobstore の使用に何らかの形で関連しているように見えます (しかし、それは説明できません)。blobstore サービスを使用する際に、他にもいくつかの問題に遭遇しました。最も問題だったのは、追加のデータストアの読み取りと書き込み (データストアで管理されている blobinfo および blobindex メタ データに関連するもので、データをブロブストアに移行することで最初に削減しようとしていたもの) でした。私にとって特に深刻な問題はこれでした: https://code.google.com/p/googleappengine/issues/detail?id=6849. これはブロブストア サービスのメモリ リークだと思います。BLOB を作成すると、データストア内の BLOB メタ データを削除することはできません。私は愚かにも 24 時間のボリュームとパフォーマンスのテストを実行し、テスト中に使用されたストレージを解放できなくなったため、この料金を永久に支払うことになります。ブロブストアは現在、非常に特定のシナリオ (つまり、永続的に静的なデータ) での使用にのみ適しているようです。頻繁に更新または変更される大量のチャーンまたはデータを含むオブジェクトは、ブロブストアに保存しないでください。]