google-app-engine - GoogleAppEngineのmemcacheのパフォーマンスが低い

Question

Memcacheは、解決策が絶対に何でもあり得るものの1つであり、おそらく何もないために、誰も実際にまともな答えを出すことはありません。ですから、私は直接的な答えを探しているのではなく、正しい方向に進むための何かを探しているのかもしれません。

一般的なリクエストについては、AppStatsの情報を以下に示します。

したがって、合計440ミリ秒のリクエストのうち、私は342ミリ秒をmemcacheに費やします。そしてここで、memcacheは非常に高速であると考えられました。私は何か間違ったことをしているに違いない。

管理コンソールでmemcacheの統計を見ると、次のようになっています。

Hit count:  3848
Miss count: 21382
Hit ratio:  15%

私はこのようなことの専門家ではありませんが、15％はひどいことだと確信しています。

上記の一般的なリクエストは少し詳細すぎて説明できませんが、基本的には、新しいエンティティを作成して配置します。これにより、親エンティティも更新および配置され、親エンティティに関連付けられているすべてのユーザーも更新および配置されます。

このすべてを通して、私は常にキーで取得し、クエリを実行しません。ああ、私はNDBを使用しているので、基本的なmemcacheのものはすべて自動的に処理されます。そのため、コード内で実際にmemcacheに手動で触れることはありません。

何か案は？

編集：これが私のリクエストの内訳です

したがって、データストアの取得と書き込みは2つしかありません。残りは自動的にmemcacheのものを処理します。なぜそんなに多くの仕事をしているのですか？このようなものを手動で処理する方が良いでしょうか？

Answer 1

データを詳しく見てみましょう。7つのmemcache書き込みは、2つのデータストア書き込みと同じくらいの時間がかかりました。これは、memcacheがデータストアよりも3.5倍高速であることを実際に証明しています。

アプリケーションへの一般的なリクエストで少なくとも3つのデータベースエンティティの更新が必要な場合（その後に関連するユーザー）の更新が続く場合、この操作を「非常に高速」にすることはできません。Memcacheは、エントリを書き込むよりもはるかに頻繁に読み取るときに役立ちます。ユーザーのレコードへの読み取りと書き込みの量が同等である場合は、このモデルのキャッシュをオフにすることを検討する必要があります。

非同期操作とタスクキューを試すこともできます。説明から、最初にエンティティを更新しようとし、更新が完了した後にのみ親を更新しようとしているように見えます。これは当然のことです。これらを同時に実行できます。これにはおそらくリファクタリングが必要ですが、それだけの価値はあります。

第二に、「関連するすべてのユーザー」を更新することは、おそらくそうかもしれません。バックグラウンドで生成されたタスクに延期されます。タスクキューには、このための非常に便利なインターフェイスがあります。「関連付けられたユーザー」はすぐには更新されませんが、おそらく更新する必要はありません。ただし、リクエストのレイテンシはそれよりも短くなります。