2010-11-06 31 views
6

Algunos perfiles muestran la representación de la plantilla como el culpable. (Estoy probando una página con SOLO consultas en caché.) Pero aún así, la plantilla es muy simple. la parte más compleja es un bucle anidado que se ejecuta 10 veces, pero si todo va bien, el bucle anidado no se ejecuta porque está en caché. (Al igual que en mis pruebas)django es muy lento

es decir

{% for p in posts %} 
--{{p.by.username}} 
--{{p.text}} 
{% cache 600 p p.timestamp %} 
    {% for img in p.images.all %} 
     --{{img.path}} 
    {% endfor %} 
{% endcache %} 
{% endfor %} 

me sale ~ 80 req/s en el prog. servidor para esta página. (descubrí que puedo multiplicar ese número por 3 en la implementación de producción) Para una comparación, obtengo 1000req/s para una plantilla trivial que solo contiene una cadena corta estática.

¿Es esto un problema conocido? ¿Cómo hago para corregir/evitarlo?

+0

¿Qué es exactamente 'lento'? –

+0

80 req/s es lento. porque no estoy haciendo nada si no se consigue un par de memcache. – oscar

+0

No es una respuesta, sino una sugerencia. ¿Has probado el almacenamiento en caché como aquí: http://djangosnippets.org/snippets/507/ –

Respuesta

2

(Al parecer no soy "kármica" lo suficiente como para enviar comentarios todavía, o que iba a publicar esto como un comentario en lugar de una respuesta)

Podría explicar qué quiere decir con "sólo consulta en caché"?

Aparte de eso, me parece que su problema podría ser que está golpeando su base de datos mucho durante la representación de la plantilla.

{% for p in posts %} 
--{{p.by.username}} {# 1 #} 
--{{p.text}} 
{% cache 600 p p.timestamp %} 
    {% for img in p.images.all %} {# 2 #} 
     --{{img.path}} 
    {% endfor %} 
{% endcache %} 
{% endfor %} 

Proporciona "publicaciones" a su plantilla; esa es una consulta, que has dicho tiene 100 resultados.

Para cada iteración sobre las publicaciones, entonces, está accediendo a la base de datos en {# 1 #} para obtener p.by, que supongo que es una clave externa a un auth.User.

Además de eso, con un caché no válido (primera ejecución), está pulsando de nuevo el db en {# 2 #} para obtener la lista de las imágenes de esa publicación.

Así que para 100 artículos, está llegando a la base de datos 201 veces por solicitud para una ejecución inicial, y 101 con una memoria caché completa para el bucle de imágenes.

Intente usar select_related con su consulta de publicaciones para obtener estos resultados adicionales en la consulta, si es posible. Algo como posts = Post.objects.select_related('by', 'images').filter(...) podría hacer el truco, aunque sé que select_related tiene límites cuando se trata de invertir claves externas y campos m2m (puede que no funcione para las imágenes, dependiendo de la estructura de su modelo).

+0

Ya uso select_related cuando la consulta no está en caché, pero como dije, en este caso solo estoy extrayendo los resultados de memcached. - Así que sí, la barra de herramientas de depuración muestra 0 consulta ejecutada. – oscar

+0

Además, dije que tiene 10 resultados, no 100. – oscar

+0

Fue en un comentario que dijiste "100 loops"; Tomé el 10 que mencionaste en tu pregunta para indicar que el bucle de imágenes internas se ejecuta diez veces para cada publicación. Lo siento si no entendí bien. – eternicode