1

I am trying to optimize performance on GAE but once I deploy I get very unstable results. It's really hard to see if each optimization actually works because datastore and memcache operations take a very variable time (it ranges from milliseconds to seconds for the same operations).

For these tests I am the only one making only one request on the application by refreshing the homepage. There is no other people/traffic happening (besides my own browser requesting images/css/js files from the page).

Edit: To make sure that the drops were not due to concurrent requests from the browser (images/css/js), I've redone the test by requesting ONLY the page with urllib2.urlopen(). Problem persists.

My questions are:

  • 1) Is this something to expect due to the fact that machines/resources are shared?
  • 2) What are the most common cases where this behavior can happen?
  • 3) Where can I go from there?

Here is a very slow datastore get (memcache was just flushed): Ultra slow datastore get Full size

Here is a very slow memcache get (things are cached because of the previous request): Slow memcache get Full size

Here is a slow but faster memcache get (same repro step as the previous one, different calls are slow): enter image description here Full size

4

1 に答える 1

0

あなたの質問に答えるために、

1) はい、ネットワークが共有されているため、リモート コールに差異が生じることが予想されます。

2) 差異が見られる最も一般的な場所は、データストア リクエストです。リクエストが大きく/遠くなるほど、より多くの差異が見られます。

3) 以下にいくつかのオプションを示します。

データストア/memcache から大量のデータをフェッチしようとしているようです。より小さなデータのチャンクを取得するように、クエリとキャッシュを再考することをお勧めします。あなたのアプリは、1 回のリクエストでそのすべてのデータを必要としますか?

アプリがリクエストごとにすべてのデータを処理する必要がある場合は、別のオプションとして、バックグラウンド タスク (cron、タスク キューなど) でデータを前処理し、結果を memcache に入れることができます。ページを提供するリクエストは、単に memcache から適切な部分を選択してページを組み立てる必要があります。

NDBを使用するという@proppyの提案は良いものです。シリアル クエリをパラレル クエリに書き直すには多少の作業が必要ですが、非同期呼び出しによる節約は非常に大きなものになる可能性があります。並列タスク (マップを使用) の恩恵を受けることができれば、なおさらです。

于 2013-07-12T21:26:27.290 に答える