En octubre de 2006, empecé a desarrollar un interés en la web y decidí también han tratado de desarrollar un sitio web. Antes de eso, trabajé durante tres años para desarrollar una aplicación Java, los desarrolladores web deben ser considerados ignorantes. Después de comparar java, php, ROR, y Python, he elegido basado pitón framework web - Django. Hasta el momento, creo que esto es una decisión sabia. Django la eficiencia del desarrollo eficiente me dejó entrar simplemente el tiempo libre de un mes, básicamente completado el desarrollo del sitio. Este es un sitio de marcadores, he añadido algunas características interesantes a las miradas de sitio un poco diferente.
He comprado un nombre de dominio y espacio de alojamiento de Dreamhost. Dreamhost Django de apoyo, y los costos del primer año sólo 180 yuanes. En noviembre de 2006, http: //www.hpbookmarks.com en la línea. Los internautas, envió un comentario de buena voluntad, "muy creativo", "algo allí"; "Algunos característica muy agradable." Al mismo tiempo, existe un consenso claro que, la velocidad de acceso es demasiado lento. De hecho, la situación no es sólo la velocidad de acceso lento, pero es bastante inestable. Muchas veces el sitio era inaccesible durante varias horas. En ese momento, no me importa, porque creo que hay dos & # 8220; razonable & # 8221; explicación. En primer lugar, yo uso la máquina virtual extranjera más barata, la visita a campo lenta es normal. En segundo lugar, Django se encuentra todavía en un estado de 0,95, los problemas de eficiencia y estabilidad también tienen normal.
Sin embargo, poco a poco descubrí que la explicación anterior es sólo una excusa para mentir a mí mismo. Muchos utilizan el sitio web dreamhost, visitarla pronto. Y también Django ha aplicado con éxito en muchos sitios de gran tamaño. Empecé a considerar seriamente la cuestión de mejorar la velocidad del sitio. Después de todo, el sitio es probable que disminuya en los primeros en perder usuarios, que nunca pueden venir de nuevo. Por último, he sido optimizado para trabajo paso a paso por debajo, e hizo lo que parecía un buen resultado.
El primer paso en el uso de Ajax para mejorar la experiencia del usuario
A medida que el tamaño de la fuente del enlace en mi sitio está basado en el número de decisión de clics, el CPC debe ser enviado al servidor y registrar el número de veces, y luego abrir el enlace web en el cliente. No encontraron ningún problema en la prueba localhost de tiempo, pero desplegado en el servidor, se sentirá una espera significativo. La solución es utilizar Ajax. Los usuarios hacen clic en el enlace de sitio web directamente después de la apertura, y luego sometidos a la del lado del servidor Ajax registrará el evento de clic. De modo que los usuarios no se sienten ningún retraso.
Un segundo paso, la lógica en Javascript del cliente
En el principio "" sitio Web a la etiqueta resalte "y" Voy a tener suerte "característica se presentan al lado del servidor, y devuelve el resultado. Más tarde, descubrí que en realidad es una gran cantidad de lógica se puede mover al cliente, implementado por el javascript la .Javascript muy potente y puede hacer una gran cantidad de lógica compleja. la lógica en el javascript cliente puede ser muy eficaz para reducir el número de servidores y la comunicación, una mayor velocidad de acceso.
El tercer paso, el proceso de liquidación
Como resultado de la forma en fastcgi, he configurado django.fcgi. Sin embargo, me encontré con el sistema en el proceso, un gran número de procesos django.fcgi está marcado <desaparecida> (pérdida de la función). Estos procesos hacen que el servidor puede no ser una visita normal. Empecé a tratar de usar estos comandos para matar el proceso, pero pronto descubrí que no puede resolver el problema fundamental. Más tarde, vi un extranjero menciona una solución en el blog, se ha cambiado el nombre django.fcgi dispatch.fcgi. El original, dreamhost dispatch.fcgi es un proceso del sistema, su solidez está garantizada de. Efectivamente, voy a django.fcgi rebautizado después dispatch.fcgi es, el fenómeno no se produce de nuevo.
El cuarto paso es optimizar sentencias SQL
Ejecutar sentencias SQL por lo general una operación que consume tiempo. Después de comprobar, me encontré con uno de mi instrucción SQL es una consulta anidada tres sub-mesa. Y este SQL también debe ser un SQL crudo, es decir, no se usa el Django O Maping. Esto significa que el caché no puede ser almacenado en caché, ejecutados cada vez que un disparo. Más fracaso es que después de mi análisis, este SQL no se puede realizar. Esto es un error de diseño, el diseño más estándar (diseño de transición). En ese momento, quiero obtener las estadísticas más precisas a través de la base de datos. Más tarde se encontró, que puede ser un valor constante en lugar de una aproximación completa. la optimización de SQL, sobre todo para evitar la ejecución de SQL innecesarios, trae el efecto es muy obvio.
El quinto paso, para reducir al mínimo el tamaño de página
Con la incorporación de más y más sitios, un día me encontré con Django casa generación ha llegado a 80k. Sé que esto es un número muy inaceptables. Empecé a revisar la página, y pronto encontré una pista. En primer lugar, debido a que el perezoso, el diseño de la página es una gran cantidad de espacio de aplicación (). En segundo lugar, porque a fin de aumentar la línea de código legible, facilitar la depuración, las páginas de cada fila se generan un salto de línea (\ n). En tercer lugar, lo peor de todo, con un gran número de CSS en línea. estilo css es bloquear directamente la etiqueta embed. Así, empecé de inmediato para resolver el diseño con CSS align, retire \ n, la CSS en línea abstracta de archivo css separada. Tan abajo, sin cambiar ningún contenido, 80k en un 57k. (Añadido: puesto que la mayoría sitios de conexión para abrir una nueva ventana, por lo que utilizar un gran número de target = _blank en el ylsdd rápido en la cabeza de los aumentos del HTML, sino que también ahorra 4k ..)
El sexto paso, una página está comprimido con gzip
Cuando Estaba eufórico a los resultados de la página de optimización publicados en bbs smth, fue lanzar directamente un cubo de agua fría. Los resultados originales de optimización del diez por ciento, y es demasiado general. ylsdd me dio una pista muy importante, desinflado. El módulo de Apache original se puede desinflar la compresión de archivos gzip, descompresión de archivos se comprime y luego se pasa al navegador. principales navegadores soportan la operación de descompresión gzip de este tipo. Por lo tanto, me uní a la opción Agregar OutputFilter DEFAULT html css js declaración en el archivo de configuración de Apache. Después de la prueba, CSS, JS comprimir archivos de texto son sólo el 25% del tamaño original. Aquí, y compartir una página web http://www.port80software.com/products/httpzip/compresscheck su función es detectar si su sitio está comprimido, y la relación de compresión y así sucesivamente.
El séptimo paso, el regreso a las páginas estáticas
Nuevos problemas vinieron de nuevo. La compresión desinflado original, sólo es compatible con los archivos estáticos. Y mi casa está Django genera dinámicamente, módulo de desinflado no se comprime. De pronto pensé, ¿por qué la página principal del sitio no puede ser páginas estáticas? Por lo tanto, he añadido un tiempo de ejecución de la API, API proporcionada esto es como el Django original, generada por las páginas dinámicas. Escribí un programa de pitón, descarga la página generada dinámicamente a través del módulo urllib2, y guardarlo como index.html. Voy a raíz del sitio asignado a la página index.html estática. Por último, mediante la definición de un linux crontab comportamiento, ejecuta cada cinco minutos acerca de este programa Python para generar un nuevo index.html. Vale la pena mencionar que, debido a razones de red, el programa de pitón puede no siempre exacta y completa descarga páginas generadas dinámicamente. Así tenemos que proceder a un algoritmo de control. En el caso de que el tamaño de página sea más que un cierto número, una cadena de suma de control que aparece en la página, sólo para ahorrar index.html. De esta manera, cada vez que el acceso de los usuarios a presentar, las páginas no dinámicos generados por el servidor, ahorrando considerablemente los costes de servidor. Las páginas estáticas y pueden ser efectivamente compresión desinflado. El resultado final, Home se comprime a 13k, el original 22%. La única diferencia es que el nuevo sitio web y presentar recomendaciones en la página principal pueden no aparecer inmediatamente. Pero pienso, esto debería ser aceptable.
Por lo tanto, la optimización del sitio es casi completa. la velocidad de acceso al sitio desde el más original que la reducción de 30 segundos a 3 segundos, debe decirse que es un salto. Aunque la velocidad de 3 segundos no es muy rápido, pero, teniendo en cuenta el objetivo de alojamiento web razones, me quedé satisfecho con este resultado. El sentimiento original de mi amigos sitio web es lenta, se puede volver a intentarlo.
programa de optimización por encima de mi experiencia personal, no necesariamente adecuado para todos los sitios. Pero nos dice un hecho. Afecta a la velocidad de acceso al sitio no es sólo la configuración del servidor, ancho de banda de la red. Tal vez un mal diseño, el programa de baja eficiencia también es factor vital. Cabe señalar que el trabajo de optimización no puede estar en una prisa para empezar. Asegúrese de cuidadosamente las condiciones específicas de estudio para obtener datos estadísticos, para encontrar el verdadero problema, a continuación, comenzar a optimizar. Cree en ti mismo y mejorar la velocidad de acceso del sitio no es imposible. Después de todo, nada es imposible. Le deseo todo el éxito.
Tomado de: http://www.360doc.com/content/07/0310/22/2459_392441.shtml
