2008-11-18 7 views
3

Le moteur de l'application Google me demande d'optimiser ce code. Quelqu'un a des idées ce que je pourrais faire?Optimisation du code Google App Engine

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

Et plus tard dans le modèle que je fais:

{% 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 }} 

Lorsque les méthodes utilisées sont les suivantes:

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 

Répondre

3

Je suppose que l'exécution d'une md5 sur chaque point à chaque fois est assez cher. Mieux vaut stocker le hachage du gravatar quelque part.

+0

10x! Je recevais l'avertissement avant que je présente le Md5 cependant. –

+0

Le code md5 est tout natif, donc je ne m'attendrais pas à ce que la surcharge d'une seule somme md5 sur une chaîne courte soit significative. –

+0

Il est encore un peu inhabituel pour une application Web d'exécuter une fonction de hachage cryptographique 100 fois par requête. Mais vous avez raison, ce n'est pas ce calcul intensif. – macbirdie

6

L'utilisation élevée du processeur sera due à la récupération de 100 entités par requête. Vous avez plusieurs options ici:

  • L'utilisation de Profile.all(). Fetch (100) sera toujours un peu plus rapide et plus facile à lire.
  • Supprime les propriétés superflues du modèle Profile. Il y a d'importantes entités de désérialisation par propriété.
  • Afficher moins d'utilisateurs par page.
  • Stockez la sortie de cette page dans memcache, et restituez à partir de memcache dès que vous le pouvez. De cette façon, vous n'avez pas besoin de générer la page souvent, donc cela n'a pas tellement d'importance si le CPU est élevé.
+0

Merci beaucoup. Je vais essayer ces optimisations tout de suite! –

0

Cela dépend de l'endroit où vous recevez l'avertissement de trop de CPU. Est-ce dans le tableau de bord, c'est probablement beaucoup de CPU de datastore, pas besoin d'optimisation.

Si la demande prend plus de 10 secondes, vous devez optimiser.

Si vous recevez régulièrement des avertissements de journal indiquant qu'une demande donnée dépasse x.xx par rapport à la limite de l'UC, cela signifie que le code de votre application prend trop de temps. Et a besoin d'optimisation.

J'ai trouvé que beaucoup de choses de modèle de Django ne prennent pas beaucoup d'application CPU (50-100 Mcycle). Si tous les champs du modèle sont précalculés.

1

J'ai eu un problème avec beaucoup de CPU utilisé pour un travail apparemment peu, qui s'est avéré être des requêtes exécutées plusieurs fois. Par exemple. Dans mon modèle Django, j'ai posté post.comments.count, puis bouclé via post.comments. Cela a donné lieu à deux exécutions - l'une obtenant le compte et l'autre obtenant les entités. Oops!

Je dirais aussi que vous prenez une copie des Appstats de Guido. Cela n'aidera pas avec le Python, mais il est très utile de voir le temps passé dans les appels API (et le temps qui les sépare - ce qui donne souvent une indication de l'endroit où vous avez Python lent).

Vous pouvez obtenir la bibliothèque ici: https://sites.google.com/site/appengineappstats/

j'ai écrit un article à ce sujet sur mon blog (avec quelques captures d'écran): http://blog.dantup.com/2010/01/profiling-google-app-engine-with-appstats

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