2008-12-12 43 views
15

Tengo una nueva instalación de django 1.0 y una página simple servida de ella tarda 5 segundos en cargarse. En la computadora de mi colega casi no lleva tiempo.django es muy lento en mi máquina

que inicie el servidor utilizando

 
python manage.py testserver 

puedo ver cada petición GET (PNG y hojas de estilo) tomar alrededor de medio segundo.

Otra cosa extraña, que creo que está relacionada, es que las pruebas funcionales para la aplicación se ejecutan mucho más lento en mi máquina con MySQL (en orden de 100 veces más lento que en la máquina de mi colega). Cuando configuro la aplicación para usar sqlite, se ejecutan bastante rápido. Me gustaría aclarar que sqlite no cambia mucho el tiempo que lleva cargar una página, pero acelera el inicio del servidor.

Parece un problema de IO, pero no veo problemas generales de rendimiento en mi máquina, aparte de django al menos.

Django se ejecuta en python2.4, estoy ejecutando Vista. También he comprobado python2.5.

Gracias ΤΖΩΤΖΙΟΥ, Totalmente debe ser un problema de DNS, porque la página se carga rápidamente tan pronto como en lugar de http://localhost:8000/app Voy a http://127.0.0.1:8000/app.

Pero, ¿qué podría ser causado por? Mi archivo de host sólo tiene dos entradas:

 
127.0.0.1 localhost 
::1   localhost 
+0

¿Es esta la primera vez que solicita la página o siempre? Además, cuando usas runserver, ¿es lo mismo? –

+0

¡Este es el error más estúpido pero me he encontrado en toda mi vida! El archivo de mi host está vacío porque en Windows 7 esas dos líneas se procesan [en el propio servidor dns] (http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within- dns-itself-why). ¡Y los mismos síntomas! Agregar la línea "127.0.0.1 localhost" lo resuelve. ¡Gracias hombre! –

Respuesta

17

Firefox tiene un problema al navegar a localhost en algunas máquinas con Windows. Puede resolverlo desactivando ipv6, que no es realmente recomendable. Usar 127.0.0.1 directamente es otra forma de resolver el problema.

+0

¿Aún cuando localhost está en el archivo de hosts? Interesante ... – Powerlord

+0

Buena información, fuzzyman! – tzot

+6

Mismo problema y solución bajo Chrome en Windows 7. –

0

desactivar el escaneado AV & ver si eso hace la diferencia. También podría ser causado por Vista. Actualice al último Service Pack e inténtelo de nuevo.

2

Creo que es el servidor de desarrollo, no está optimizado para la velocidad ni la seguridad. Noté que los archivos estáticos que sirven especialmente (es decir, los medios) son lentos.

3

Dado que informa que la máquina de su amigo no tiene retrasos, y supongo que la suya y la suya son computadoras comparables, podría tratarse de un problema relacionado con el DNS. Intente agregar la dirección IP del cliente y del servidor al archivo de hosts del servidor.

Si ejecuta Django en * nix, es el archivo /etc/hosts. Si lo ejecuta en MS Windows, es el archivo %WINDIR%\SYSTEM32\DRIVERS\ETC\HOSTS. (Son archivos de texto y pueden ser editados por su editor de texto favorito.)

+0

5 segundos de retraso siempre me suena como un problema de resolución de nombres. –

1

Y si todo lo demás falla, siempre puede cProfile su aplicación y ver dónde está exactamente el cuello de botella.

1

He tenido el mismo problema en el pasado. Se puede resolver eliminando la siguiente línea de su archivo de hosts.

::1   localhost 

Una vez que se haya ido, debería poder usar localhost nuevamente, rápidamente.

2

Tuve el mismo problema también, lo he notado con Firefox en las máquinas Vista y Windows 7. El acceso al servidor de desarrollo 127.0.0.1:8000 resolvió el problema.

0

Para eludir por completo localhost sin alterar el archivo de hosts o cualquier configuración en Firefox puede instalar el complemento Redirector y crear una regla para redirigir desde localhost a 127.0.0.1. Use estas configuraciones

Include pattern : http://localhost* 
Redirect to  : http://127.0.0.1$1 

Deje los otros campos vacíos.

7

Ninguna de estas publicaciones me ha ayudado. En mi caso específico, Justin Carmony me dio la respuesta.

Problema

me mapeo [nombre de host] .local a 127.0.0.1 en mi/etc/hosts para fines de desarrollo fácil y peticiones DNS estaban tomando 5 segundos a resolver. A veces se resolverían rápidamente, otras veces no lo harían.

Solución

Apple está usando .local que hacer un poco de magia en Bonjour nuevo Snow Leopard construye (creo que empecé a notar que después de actualizar a 10.6.8) y Mac OS X Lion. Si cambia su nombre de host dev para comenzar con local en lugar de finalizar con local, debería estar todo listo. Además, puedes usar cualquier TLD además de local y funcionará sin conflictos.

Ejemplo

test.local podría convertirse en:

  • local.test.com
  • test.dev
  • prueba [nada pero local]

. y su entrada del archivo de hosts leería:

local.test.com 127.0.0.1 

Nota: Esta solución tiene la ventaja añadida de ser un subdominio de [nombre de host] .com que hace que sea más fácil para especificar un nombre de dominio de aplicaciones para las API de Facebook, etc.

que también desee Ejecute dscacheutil -flushcache en la terminal para una buena medida después de actualizar/etc/hosts

+0

esto también lo resolvió para mí y soy usuario de Windows :-) ¡gracias! – Esben

1

Tuve el mismo problema pero fue causado por mysqld.

La aplicación funcionó bastante rápido en producción con wsgi y un servidor mysql en el mismo host pero lento en el entorno de desarrollo con la opción django runserver y un servidor remoto mysql.

Me di cuenta usando "show processlist" que las conexiones en la base de datos se atascan en el estado "iniciar sesión" con el usuario "usuario no autenticado" y esto me hace notar que el problema está en el proceso de autenticación.

Buscando el verdadero problema, finalmente me di cuenta de que mysqld estaba tratando de obtener el nombre dns de mi ip y desactivando el nombre dns de resolución, arreglé el problema.

Para hacer eso, puede agregar esta línea a mi.CNF archivo:

skip-name-resolve

0

i tiene el mismo problema.

la solución era:

  • yo estaba tratando de iniciar una versión necesitas cigarros que se ha implementado usualy en un servidor web en la producción.
  • Los archivos estáticos en la producción fueron servidos por una configuración de Apache y no con Django estática sirven

así que simplemente no comentada nuevo mi estática sirven URLs:/

1

Promueve a Django 1.3 o posterior.

Si todavía tiene este problema en 2012 (usando Chrome), asegúrese de estar actualizando. En 1.3, se corrigió un bug relacionado con la lentitud cuando el servidor de desarrollo tenía un único subproceso.

La actualización resolvió mis problemas. Estaba ejecutando Django 1.2 ya que es el valor predeterminado en Debian Squeeze.