La mia applicazione di django è diventata dolorosamente lenta nella produzione. Il problema è dovuto a domande complesse o non indicizzate.Profilo Django
C'è qualche modo django-ish per profilare la mia applicazione?
Provare il Django Debug Toolbar. Ti mostrerà quali query vengono eseguite su ciascuna pagina e quanto tempo impiegano. È uno strumento davvero utile, potente e facile da usare.
Inoltre, leggere i consigli sulle prestazioni di Django in Database access optimization dalla documentazione.
E Django performance tips di Jacob Kaplan-Moss.
Basta digitare "django-profiling" su google, si otterrà questi collegamenti (e non solo):
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/
Personalmente sto usando il approccio middleware - cioè ogni utente può attivare un flag di "profilazione" memorizzato in una sessione, e se il mio middleware di profilazione rileva che è stato impostato un flag, usa il modulo di Python hotshot lik e questo:
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: Per profilatura query SQL http://github.com/robhudson/django-debug-toolbar citato da Konstantin è una cosa bella - ma se le query sono veramente lento (probabilmente perché ci sono centinaia o migliaia di loro), allora sarete in attesa tempo folle fino a quando non viene caricato in un browser - e quindi sarà difficile navigare a causa della lentezza. Inoltre, django-debug-toolbar non è in grado di fornire utili informazioni sugli interni delle richieste AJAX.
EDIT2: django-extensions ha un grande comando di profilazione costruito in:
https://github.com/django-extensions/django-extensions/blob/master/docs/runprofileserver.rst
solo fare questo e voilà:
$ mkdir /tmp/my-profile-data
$ ./manage.py runprofileserver --kcachegrind --prof-path=/tmp/my-profile-data
http://code.google.com/p/django-profile/ è un'applicazione django di un profilo utente. non è usato come profilazione django :) – dzen
@dzen: Hah, buon punto, doveva essere: http://code.google.com/p/django-profiling/ :-) –
se ti chiedi come leggere il dump di profiler dopo l'esecuzione di 'python manage.py runprofileserver --prof-path =/path/to/dir', segui questo blog: http://www.darkcoding.net/software/profiling-django-for-cpu-bound- apps /. – Neara
Quando i punti di vista non sono HTML, per esempio JSON, utilizzare semplici metodi middleware per la profilazione.
Ecco un paio di esempi:
https://gist.github.com/1229685 - catturare tutte le chiamate SQL è andato nella vista
https://gist.github.com/1229681 - profilo tutte le chiamate a metodi utilizzati per creare la vista
Per profilatura di accesso ai dati (che è dove il collo di bottiglia è la maggior parte del tempo) controlla django-live-profiler. A differenza di Django Debug Toolbar, raccoglie simultaneamente i dati su tutte le richieste ed è possibile eseguirli in produzione senza sovraccarico di prestazioni eccessive o esponendo gli interni delle app.
non supporta 1.6 e sopra, nessuna attività per più di un anno. –
Per tutto quello che KCachegrind fan, trovo che è molto facile da usare la shell in tandem con fantastica prova di Django Client per generare log di profilo on-the-fly, in particolare nella produzione. Ho usato questa tecnica ora in diverse occasioni perché ha un tocco leggero - non sono richiesti fastidiosi middleware o applicazioni Django di terze parti! hotshot2cachegrind
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()
Per visualizzare il registro risultante, ho usato::
Ad esempio, per il profilo di una visione particolare che sembra essere in esecuzione lenta, si potrebbe rompere aprire la shell e digitare il codice
Ma ci sono anche altre opzioni:
senza vergogna qui, ma di recente ho fatto https://github.com/django-silk/silk per questo scopo. È in qualche modo simile alla toolbar di Django, ma con la storia, il profiling del codice e un controllo più fine su tutto.
Ottenere il problema del middleware 'Non è stato possibile trovare gestori per il programma di registrazione "silk.middleware"' –
Attenzione per la barra degli strumenti di Django Debug - L'ho spento durante lo sviluppo e il rendering della pagina è stato significativamente più veloce sul mio laptop (a dire il vero a bassa potenza) - guarda nel server di sviluppo per vedere quanti dati stai scaricando. –
django-debug-toolbar mi aiuta a vedere quante query django-orm colpisce il db, e possiamo vedere come la funzione select_related() faccia in modo che il trucco la colpisca di meno. – panchicore
@ dominic-rodger Non mi sono reso conto di quanto più lentamente la barra degli strumenti di Debug ha reso le cose in evoluzione. Le mie query SQL erano piccole (30 ms) ma il tempo di CPU era molto alto (800 ms). Un'altra pagina che stavo accordando aveva sql times di 300ms e tempo di CPU di 8000ms - così ho continuato a cercare di trovare la fonte del problema. Disattivare Django Toolbar dalle cose veloci. 3 anni dopo, ancora rilevanti. – Esteban