Оптимизация кода Google App Engine

Question

Движок приложения Google говорит мне оптимизировать этот код. Кто-нибудь есть идеи, что я мог сделать?

def index(request):
    user = users.get_current_user()
    return base.views.render('XXX.html', 
                 dict(profiles=Profile.gql("").fetch(limit=100), user=user))

А позже в шаблоне я делаю:

{% for profile in profiles %}
  <a href="/profile/{{profile.user.email}}/"><img src="{{profile.gravatarUrl}}"></a>
  <a href="/profile/{{profile.user.email}}/">{{ profile.user.nickname }}</a>
  <br/>{{ profile.shortDisplay }}

Где используются следующие методы:

def shortDisplay(self):
    return "%s/day; %s/week; %s days" % (self.maxPerDay, self.maxPerWeek, self.days)

def gravatarUrl(self):
    email = self.user.email().lower()
    default = "..."
    gravatar_url = "http://www.gravatar.com/avatar.php?"
    gravatar_url += urllib.urlencode({'gravatar_id':hashlib.md5(email).hexdigest(), 
        'default':default, 'size':"64"})
    return gravatar_url

Answer 1

Высокая загрузка ЦП будет вызвана получением 100 сущностей за запрос. У вас есть несколько вариантов здесь:

• Использование Profile.all (). Fetch (100) будет немного быстрее, кроме того, его будет легче читать.
• Удалите все посторонние свойства из модели профиля. Существуют существенные накладные десериализационные сущности для каждого свойства.
• Отображать меньше пользователей на страницу.
• Сохраните выходные данные этой страницы в memcache и визуализируйте из memcache, когда сможете. Таким образом, вам не нужно часто генерировать страницу, поэтому не имеет большого значения, если у него высокая загрузка ЦП.

Answer 2

Я бы предположил, что выполнение хеша md5 для каждого элемента каждый раз довольно дорого. Лучше хранить где-нибудь хеш с электронной почтой.

Answer 3

У меня была проблема с большим количеством ЦП, который использовался для, казалось бы, небольшой работы, которая, как оказалось, не выполнялась многократно. Например. В моем шаблоне Django я сделал post.comments.count, а затем перебрал post.comments. Это привело к двум казням - один получил счетчик, а другой получил сущности. Упс!

Я бы также сказал, возьмите копию Appstats Гвидо. С Python это не поможет, но очень полезно видеть время, потраченное на вызовы API (и время между ними - что часто дает представление о том, где у вас медленный Python).

Вы можете получить библиотеку здесь: https://sites.google.com/site/appengineappstats/

Я написал об этом статью в своем блоге (с некоторыми скриншотами): http://blog.dantup.com/2010/01/profiling-google-app-engine-with-appstats

Appstats http://blog.dantup.com/pi/appstats_4_thumb.png

Answer 4

Зависит от того, где вы получаете предупреждение о слишком большой загрузке процессора.

Это на приборной панели, это, вероятно, много ЦП хранилища данных, нет необходимости в оптимизации.

Если запрос занимает более 10 секунд, вам нужно оптимизировать.

Если вы получаете регулярные предупреждения в журнале о том, что определенный запрос превышает ограничение ЦП на x.xx, это означает, что код вашего приложения занимает слишком много времени. И нуждается в оптимизации.

Я обнаружил, что большая часть шаблонов Django не занимает много процессорного времени приложения (50-100 Mcycle). Если все поля для шаблона предварительно рассчитаны.