Profilage Django

Essayez la barre d’outils de débogage de Django . Il vous montrera quelles requêtes sont exécutées sur chaque page et combien de temps elles prennent. C’est un outil très utile, puissant et facile à utiliser.

Lisez également les recommandations concernant les performances de Django dans l’ optimisation de l’ access aux bases de données à partir de la documentation.

Et conseils de performance Django par Jacob Kaplan-Moss.

Tapez simplement “django-profiling” sur Google, vous obtiendrez ces liens (et plus encore):

http://code.djangoproject.com/wiki/ProfilingDjango

http://code.google.com/p/django-profiling/

http://www.rkblog.rk.edu.pl/w/p/django-profiling-hotshot-and-kcachegrind/

Personnellement, j’utilise l’approche du middleware – c.-à-d. Que chaque utilisateur peut basculer un indicateur de profilage stocké dans une session et si mon middleware de profilage remarque qu’un indicateur a été défini, il utilise le module hotshot de Python comme ceci:

def process_view(self, request, view_func, view_args, view_kwargs): # setup things here, along with: settings.DEBUG=True # to get a SQL dump in connection.queries profiler = hotshot.Profile(fname) response = profiler.runcall(view_func, request, *view_args, **view_kwargs) profiler.close() # process results return response 

EDIT: Pour profiler les requêtes SQL http://github.com/robhudson/django-debug-toolbar mentionné par Konstantin est une bonne chose – mais si vos requêtes sont vraiment lentes (probablement parce qu’il y en a des centaines ou des milliers), alors vous J’attendrai un temps fou jusqu’à ce qu’il soit chargé dans un navigateur – et il sera alors difficile de naviguer à cause de la lenteur. De plus, django-debug-toolbar est incapable de donner un aperçu utile des requêtes internes d’AJAX.

EDIT2: django-extensions dispose d’une excellente commande de profilage intégrée:

https://github.com/django-extensions/django-extensions/blob/master/docs/runprofileserver.rst

Faites ceci et le tour est joué:

 $ mkdir /tmp/my-profile-data $ ./manage.py runprofileserver --kcachegrind --prof-path=/tmp/my-profile-data 

Pour le profilage de l’access aux données (qui est l’endroit où le goulot d’étranglement est la plupart du temps), consultez django-live-profiler . Contrairement à la barre d’outils de débogage de Django, elle collecte des données sur toutes les requêtes simultanément et vous pouvez les exécuter en production sans trop de performances et sans exposer les composants internes de votre application.

Plug sans vergogne ici, mais j’ai récemment fait https://github.com/django-silk/silk à cette fin. C’est un peu similaire à la barre d’outils django mais avec l’historique, le profilage de code et un contrôle plus fin sur tout.

Pour tous les fans de KCacheGrind, je trouve très facile d’utiliser le shell en tandem avec le fantastique test Client de Django pour générer des journaux de profil à la volée, en particulier en production. J’ai utilisé cette technique à plusieurs resockets car elle est légère – aucun logiciel médiateur ou application Django tierce n’est nécessaire!

Par exemple, pour profiler une vue particulière qui semble fonctionner lentement, vous pouvez ouvrir le shell et taper ce code:

 from django.test import Client import hotshot c = Client() profiler = hotshot.Profile("yourprofile.prof") # saves a logfile to your pwd profiler.runcall(c.get, "/pattern/matching/your/view/") profiler.close() 

Pour visualiser le journal résultant, j’ai utilisé hotshot2cachegrind:

• http://kcachegrind.sourceforge.net/html/ConsortingbPython.html

Mais il y a aussi d’autres options:

• http://www.vrplumber.com/programming/runsnakerun/
• https://code.djangoproject.com/wiki/ProfilingDjango

Lorsque les vues ne sont pas HTML, par exemple JSON, utilisez des méthodes middleware simples pour le profilage.

Voici quelques exemples:

https://gist.github.com/1229685 – capturer tous les appels SQL est entré dans la vue

https://gist.github.com/1229681 – profilez tous les appels de méthode utilisés pour créer la vue