php - recargar - no cargar cache

Guardado en caché, PHP generado Las miniaturas se cargan lentamente (19)

¿Entonces su script PHP está generando las miniaturas en cada carga de página? En primer lugar, si las imágenes que se están viendo en miniatura no cambian con tanta frecuencia, ¿podría configurar una memoria caché para que no tengan que analizarse cada vez que se cargue la página? En segundo lugar, ¿su script PHP usa algo como imagecopyresampled() para crear las miniaturas? Esa es una muestra de resolución no trivial y la secuencia de comandos PHP no devolverá nada hasta que no se reduzca. Usar imagecopymerged() reducirá la calidad de la imagen, pero acelera el proceso. ¿Y qué reducción estás haciendo? ¿Son estas miniaturas 5% del tamaño de la imagen original o 50%? Es probable que un tamaño mayor de la imagen original conduzca a una desaceleración, ya que el script PHP tiene que obtener la imagen original en la memoria antes de que pueda reducirla y generar una miniatura más pequeña.

Pregunta Parte A ▉ (100 bountys, otorgado)
La pregunta principal era cómo hacer que este sitio cargue más rápido. Primero necesitábamos leer estas cascadas. Gracias a todos por sus sugerencias sobre el análisis de lectura de cascada. Evidente de los diversos gráficos de cascada que se muestran aquí es el principal cuello de botella: las miniaturas generadas por PHP. La carga de jquery sin protocolo de CDN asesorada por David obtuvo mi recompensa, aunque hizo que mi sitio sea solo un 3% más rápido en general y sin responder al cuello de botella principal del sitio. Tiempo para aclarar mi pregunta y otra recompensa:

Pregunta Parte B ▉ (100 bountys, otorgado)
El nuevo enfoque ahora era resolver el problema que tenían las imágenes de 6 jpg, que están causando la mayor parte del retraso de carga. Estas 6 imágenes son miniaturas generadas por PHP, diminutas y de solo 3 ~ 5 kb, pero se cargan con relativa lentitud. Observe el " tiempo hasta el primer byte " en los diversos gráficos. El problema no se resolvió, pero una recompensa fue para James, que corrigió el error del encabezado que RedBot underlined : "Una solicitud condicional If-Modified-Since devolvió el contenido completo sin cambios". .

Pregunta Parte C ▉ (mi última recompensa: 250 puntos)
Desafortunadamente, después de que se corrigió incluso el error del encabezado de REdbot.org, la demora causada por las imágenes generadas por PHP permaneció intacta. ¿Qué demonios piensan estas diminutas miniaturas de 3 ~ 5 Kb? Toda esa información de encabezado puede enviar un cohete a la luna y viceversa. Cualquier sugerencia sobre este cuello de botella es muy apreciada y tratada como posible respuesta, ya que estoy atrapado en este problema de embotellamiento durante ya siete meses. Mi agradecimiento de antemano.

[Alguna información de fondo en mi sitio: CSS está en la parte superior. JS en la parte inferior (Jquery, JQuery UI, compró el menú awm / menu.js motores, pestañas js motor, video swfobject.js) Las líneas negras en la segunda imagen muestran qué está iniciando qué cargar. El robot enojado es mi mascota "ZAM". Él es inofensivo y muchas veces más feliz.]

Cascada de carga: cronológico | http://webpagetest.org

Dominios paralelos agrupados | http://webpagetest.org

Site-Perf Waterfall | http://site-perf.com

Cascada Pingdom Tools | http://tools.pingdom.com

Cascada GTmetrix | http://gtmetrix.com

¿Ha intentado configurar varios subdominios en el servidor web NGINX especialmente para servir datos estáticos como imágenes y hojas de estilo? Algo útil ya se pudo encontrar en este tema .

¿Has intentado reemplazar los thp generados por php por imágenes regulares para ver si hay alguna diferencia? El problema podría estar presente - un error en su código php que lleva a la regeneración de la miniatura en cada invocación del servidor - un retraso en su código (sleep (?)) Asociado con un problema de reloj - un problema difícil que causa una muy mala condición de carrera ya que todas las miniaturas se cargan / generan al mismo tiempo.

Como algunos navegadores solo descargan 2 descargas paralelas por dominio, no podrías agregar dominios adicionales para fragmentar las solicitudes en dos o tres nombres de host diferentes. eg 1.imagecdn.com 2.imagecdn.com

Creo que en lugar de utilizar ese script generador de miniaturas, debes probar TinySRC para una generación rápida y rápida de miniaturas alojadas en la nube. Tiene una API muy simple y fácil de usar, puedes usar como:

http://i.tinysrc.mobi/ [height] / [width] /http://domain.tld/path_to_img.jpg

[ancho] (opcional): - Este es un ancho en píxeles (que anula el tamaño adaptativo o familiar). Si se le agrega el prefijo ''-'' o ''x'', restará o reducirá a un porcentaje del tamaño determinado.

[altura] (opcional): - Esta es una altura en píxeles, si el ancho también está presente. También anula el tamaño adaptativo o familiar y puede ir precedido de ''-'' o ''x''.

Puedes consultar el resumen de la API here

FAQ

¿Qué me cuesta tinySrc?

Nada.

¿Cuándo puedo comenzar a usar tinySrc?

Ahora.

¿Qué tan confiable es el servicio?

No garantizamos el servicio tinySrc. Sin embargo, se ejecuta en una importante infraestructura de nube distribuida , por lo que proporciona una alta disponibilidad en todo el mundo. Debería ser suficiente para todas sus necesidades.

¿Qué tan rápido es?

tinySrc almacena en caché el tamaño de las imágenes en la memoria y en nuestro almacén de datos por hasta 24 horas , y no recuperará la imagen original cada vez. Esto hace que los servicios sean increíblemente rápidos desde la perspectiva del usuario. (Y reduce la carga del servidor como un agradable efecto secundario).

Buena suerte. Solo una sugerencia, ya que no nos está mostrando el código: p

En cuanto a las miniaturas retrasadas, intente realizar una llamada a flush() inmediatamente después de la última llamada al header() en el script de generación de miniaturas. Una vez hecho esto, regenere su gráfico de cascada y vea si la demora ahora está en el cuerpo en lugar de los encabezados. Si es así, debe analizar detenidamente la lógica que genera y / o genera los datos de la imagen.

La secuencia de comandos que maneja las miniaturas debería utilizar algún tipo de almacenamiento en caché, de modo que las acciones que realice en las imágenes que está sirviendo solo se produzcan cuando sea absolutamente necesario. Parece que se está llevando a cabo alguna operación costosa cada vez que se publican las miniaturas, lo que retrasa el resultado (incluidos los encabezados) del guión.

En primer lugar, debe manejar las solicitudes If-Modified-Since y de manera apropiada, como dijo James. Ese error indica que: "Cuando pregunto a su servidor si esa imagen se ha modificado desde la última vez, envía toda la imagen en lugar de un simple sí / no".

El tiempo entre la conexión y el primer byte generalmente es el tiempo que su script PHP tarda en ejecutarse. Es evidente que algo está sucediendo cuando esa secuencia de comandos comienza a ejecutarse.

¿Has considerado perfilarlo? Puede tener algunos problemas.
En combinación con el problema anterior, su secuencia de comandos puede estar ejecutándose muchas más veces de las necesarias. Idealmente, debería generar pulgares solo si la imagen original se modifica y enviar pulgares en caché para cada otra solicitud. ¿Ha comprobado que la secuencia de comandos está generando las imágenes innecesariamente (por ejemplo, para cada solicitud)?

Generar encabezados adecuados a través de la aplicación es un poco complicado, además de que pueden ser sobreescritos por el servidor. Y usted está expuesto al abuso ya que cualquier persona que envíe encabezados de solicitud sin caché causará que su generador de miniaturas se ejecute continuamente (y suba cargas). Por lo tanto, si es posible, intente guardar los pulgares generados, llame a las imágenes guardadas directamente desde sus páginas y administre los encabezados desde .htaccess . En este caso, ni siquiera necesitaría nada en su .htaccess si su servidor está configurado correctamente.

Aparte de esto, puede aplicar algunas de las ideas de optimización brillante de las partes de rendimiento de esta pregunta SO agradable general sobre cómo hacer sitios web de la manera correcta , como dividir sus recursos en subdominios sin cookies, etc. Pero, en cualquier caso, una imagen 3k no debería tomar un segundo para cargar, esto es evidente cuando se compara con otros elementos en los gráficos. Debería intentar detectar el problema antes de optimizarlo.

Encontré la URL de su sitio web y verifiqué un archivo jpg individual desde la página de inicio. Mientras que el tiempo de carga es razonable ahora (161ms), está esperando 126ms, que es demasiado.

Tus últimos encabezados modificados están configurados para el sábado, 01 de enero de 2011 12:00:00 GMT, que parece demasiado "redondo" para ser la verdadera fecha de generación ;-)

Como el control de caché es "público, max-age = 14515200", los encabezados arbitrarios de última modificación pueden causar problemas después de 168 días.

De todos modos, este no es el verdadero motivo de las demoras.

Tienes que verificar qué hace tu generador de miniaturas cuando la miniatura ya existe y lo que podría consumir tanto tiempo verificando y entregando la imagen.

Puede instalar xdebug para perfilar el script y ver dónde están los cuellos de botella.

Tal vez todo utiliza un marco o se conecta a alguna base de datos para nada. He visto mysql_connect () muy lento en algunos servidores, principalmente porque se conectaban usando TCP y no socket, a veces con algunos problemas de DNS.

Entiendo que no puede publicar su generador de pago aquí, pero me temo que hay demasiados problemas posibles ...

Esto es solo una suposición descabellada ya que no he visto su código, pero sospecho que las sesiones pueden estar desempeñando un papel aquí, la siguiente es de la entrada de PHP Manual en session_write_close() :

Los datos de la sesión generalmente se almacenan después de que finalizó su secuencia de comandos sin la necesidad de llamar a session_write_close (), pero como los datos de la sesión están bloqueados para evitar escrituras concurrentes, solo una secuencia de comandos puede operar en una sesión en cualquier momento. Al usar conjuntos de marcos junto con sesiones, experimentará que los marcos se carguen uno por uno debido a este bloqueo. Puede reducir el tiempo necesario para cargar todos los cuadros finalizando la sesión tan pronto como se hayan realizado todos los cambios en las variables de la sesión.

Como dije, no sé qué está haciendo tu código, pero esos gráficos parecen extrañamente sospechosos. Tuve un problema similar cuando codifiqué una función de publicación de archivos de varias partes y tuve el mismo problema. Al servir un archivo grande, no pude obtener la funcionalidad multiparte para trabajar ni pude abrir otra página hasta que se completó la descarga. Llamar a session_write_close() solucionó mis problemas.

Estoy lejos de ser un experto pero ...

Con respecto a esto: "Una solicitud condicional If-Modified-Since devolvió el contenido completo sin cambios". y mis comentarios

El código usado para generar las Miniaturas debe verificar lo siguiente:

¿Hay una versión en caché de la miniatura?
Es la versión almacenada en caché más nueva que la imagen original.

Si alguno de estos es falso, la miniatura debería generarse y devolverse sin importar qué. Si ambos son verdaderos, se debe realizar la siguiente comprobación:

¿Hay un encabezado HTTP_IF_MODIFIED_SINCE?
Es la última vez modificada de la versión almacenada en caché la misma que HTTP_IF_MODIFIED_SINCE

Si cualquiera de estos es falso, se devolverá la miniatura en caché.

Si ambos son verdaderos, se debe devolver un estado http 304. No estoy seguro de si es necesario, pero también devuelvo personalmente los encabezados Cache-Control, Expires y Last-Modified junto con el 304.

Con respecto a GZipping, me han informado que no hay necesidad de imágenes GZip, así que ignora esa parte de mi comentario.

Editar: no noté tu adición a tu publicación.

session_cache_limiter(''public''); header("Content-type: " . $this->_mime); header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT"); // I''m sure Last-Modified should be a static value. not dynamic as you have it here. header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

También estoy seguro de que su código necesita comprobar el encabezado HTTP_IF_MODIFIED_SINCE y reaccionar ante él. Simplemente configurar estos encabezados y su archivo .htaccess no proporcionará el resultado requerido.

Creo que necesitas algo como esto:

$date = ''D, d M Y H:i:s T''; // DATE_RFC850 $modified = filemtime($filename); $expires = strtotime(''1 year''); // 1 Year header(sprintf(''Cache-Control: %s, max-age=%s'', ''public'', $expires - time())); header(sprintf(''Expires: %s'', date($date, $expires))); header(sprintf(''Last-Modified: %s'', date($date, $modified))); header(sprintf(''Content-Type: %s'', $mime)); if(isset($_SERVER[''HTTP_IF_MODIFIED_SINCE''])) { if(strtotime($_SERVER[''HTTP_IF_MODIFIED_SINCE'']) === $modified) { header(''HTTP/1.1 304 Not Modified'', true, 304); // Should have been an exit not a return. After sending the not modified http // code, the script should end and return no content. exit(); } } // Render image data

Intente ejecutar las pruebas Y! Slow y Page Speed en su sitio / página, y siga las pautas para resolver posibles cuellos de botella de rendimiento. Deberías obtener grandes ganancias de rendimiento una vez que puntúes más alto en Y! Slow o Page Speed.

Estas pruebas le dirán qué está mal y qué cambiar.

Investigar el uso de PHP de los datos de la sesión. Tal vez (solo tal vez), el script PHP generador de imágenes está esperando para obtener un bloqueo en los datos de la sesión, que está bloqueada por la página principal que sigue representando u otros scripts de renderización de imágenes. Esto haría que todas las optimizaciones de JavaScript / navegador sean casi irrelevantes, ya que el navegador espera al servidor.

PHP bloquea los datos de sesión para cada secuencia de comandos en ejecución, desde el momento en que se inicia el manejo de la sesión hasta el momento en que finaliza la secuencia de comandos o cuando se llama a session_write_close (). Esto efectivamente serializa cosas. Consulte la página de PHP en las sesiones, especialmente los comentarios, como este .

La mayoría del problema lento es su TTFB (Tiempo hasta el primer byte) demasiado alto. Esta es una tarea difícil de abordar sin tener que intimar con los archivos de configuración del servidor, el código y el hardware subyacente, pero puedo ver que es desenfrenado en cada solicitud. Tienes demasiadas barras verdes (malas) y muy pocas barras azules (buenas). Es posible que desee dejar de optimizar la interfaz por un momento, ya que creo que ha hecho mucho en esa área. A pesar del adagio de que "el 80% -90% del tiempo de respuesta del usuario final se gasta en la interfaz ", creo que el suyo está ocurriendo en el back-end.

TTFB es material de backend, material del servidor, procesamiento previo antes de la salida y el apretón de manos.

Mida la ejecución del código para encontrar cosas lentas como consultas lentas de bases de datos, el tiempo de entrada y salida de funciones / métodos para encontrar funciones lentas. Si usas php, prueba Firephp . A veces se trata de una o dos consultas lentas que se ejecutan durante el inicio o la inicialización, como extraer información de la sesión o verificar la autenticación y otras cosas. La optimización de las consultas puede generar buenas ganancias de rendimiento. Algunas veces, el código se ejecuta usando php prepend o spl autoload para que se ejecuten en todo. Otras veces puede ser mal configurado, apache conf y ajustes que salvan el día.

Busque bucles ineficientes. Busque llamadas a la memoria lenta de cachés o operaciones lentas de E / S causadas por unidades de disco defectuosas o uso de espacio en disco alto. Busque los usos de la memoria y lo que se usa y dónde. Ejecute una página web con la prueba repetida de 10 ejecuciones en una sola imagen o archivo utilizando solo la primera vista desde diferentes lugares del mundo y no en la misma ubicación. Y lea sus registros de acceso y errores, demasiados desarrolladores los ignoran y confían solo en los errores publicados en la pantalla. Si su proveedor de alojamiento web tiene soporte, pídales ayuda, si no pueden pedir cortésmente ayuda de todos modos, no va a doler.

Puede probar la Preinscripción de DNS para combatir los muchos dominios y recursos, http://html5boilerplate.com/docs/DNS-Prefetching/

¿Es el servidor tuyo un servidor bueno / decente? A veces un servidor mejor puede resolver muchos problemas. Soy fan del '' hardware es barato, los programadores son caros '' mentalidad, si tienes la oportunidad y el dinero mejora un servidor. Y / O use un CDN como maxcdn o cloudflare o similar.

¡Buena suerte!

(ps no trabajo para ninguna de estas compañías. Además, el enlace de nube nublada anterior argumentará que TTFB no es tan importante, lo tiré allí para que pueda obtener otra toma).

Lamento decir que proporcionas pocos datos. Y ya tenías algunas buenas sugerencias.

¿Cómo estás sirviendo esas imágenes? Si los está transmitiendo a través de PHP, está haciendo algo muy malo, incluso si ya se han generado.

NUNCA TRANSMITE IMÁGENES CON PHP. Disminuirá la velocidad de su servidor, sin importar la forma en que lo use.

Póngalos en una carpeta accesible, con un URI significativo. Luego llámalos directamente con su URI real. Si necesita la generación sobre la marcha, debe poner .htaccess en el directorio de imágenes que redirecciona a un generador php-script solo si falta la imagen solicitada. (esto se llama estrategia de caché bajo demanda).

Hacer eso arreglará la sesión de php, el proxy del navegador, el almacenamiento en caché, ETAGS, todo al mismo tiempo.

WP-Supercache usa esta estrategia, si está configurada correctamente.

Escribí esto hace un tiempo ( http://code.google.com/p/cache-on-request/source/detail?r=8 ), las últimas revisiones están rotas, pero supongo que 8 o menos deberían funcionar y tú puedes tome el .htaccess como ejemplo solo para probar cosas (aunque hay mejores formas de configurar el .htaccess de lo que solía hacerlo).

Describí esa estrategia en esta publicación de blog ( http://www.stefanoforenza.com/need-for-cache/ ). Probablemente esté mal escrito, pero puede ayudar a aclarar las cosas.

Lectura adicional: http://meta.wikimedia.org/wiki/404_handler_caching

Primero, usar esos dominios múltiples requiere varias búsquedas de DNS. Sería mejor combinar muchas de esas imágenes en un sprite en lugar de distribuir las solicitudes.

En segundo lugar, cuando cargo su página, veo la mayor parte del bloqueo (~ 1.25s) en all.js. Veo que comienza con (una versión anterior de) jQuery. Debe hacer referencia a eso desde el CDN de Google, no solo para disminuir el tiempo de carga , sino también para evitar una solicitud HTTP .

Específicamente, las bibliotecas jQuery y jQuery UI más recientes se pueden consultar en estas URL (consulte esta publicación si le interesa por qué omití http: :

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js //ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

Si está utilizando uno de los temas predeterminados de jQuery UI, también puede extraer su CSS y las imágenes de Google CDN .

Con el hosting jQuery optimizado, también debe combinar awmlib2.js y tooltiplib.js en un solo archivo.

Si abordas esas cosas, deberías ver una mejora significativa.

Si no hay una buena razón (generalmente no la hay), sus imágenes no deberían invocar al intérprete de PHP.

Cree una regla de reescritura para su servidor web que servidores de la imagen directamente si se encuentra en el sistema de archivos. Si no es así, redirija a su script PHP para generar la imagen. Cuando edite la imagen, cambie el nombre de archivo de las imágenes para obligar a los usuarios que tienen una versión en caché a buscar la imagen recién editada.

Si al menos no funciona, ahora no tendrá nada que ver con la forma en que se crean y verifican las imágenes.

Solo una simple suposición porque este tipo de análisis requiere una gran cantidad de pruebas A / B: su dominio .ch parece ser difícil de alcanzar (bandas largas y verdes antes de que llegue el primer byte).

Esto significaría que el sitio web .ch está mal hospedado o que su ISP no tiene una buena ruta hacia ellos.

Dados los diagramas, esto podría explicar un gran golpe de rendimiento.

En una nota al margen, hay esta genial herramienta cuzillion que podría ayudarte a resolver las cosas dependiendo de tu orden de carga de recursos.

Tuve un problema similar hace unos días y encontré head.js. Es un complemento de Javascript que le permite cargar todos los archivos JS en paralelo. Espero que ayude.

Wow, es difícil explicar cosas usando esa imagen ... Pero aquí, algunos intentos:

los archivos 33-36 se cargan tan tarde, porque se cargan dinámicamente dentro del swf, y el swf (25) se carga por completo antes de cargar cualquier contenido adicional
los archivos 20 y 21 son quizás (no sé, porque no conozco tu código) bibliotecas cargadas por all.js (11), pero para que 11 se ejecuten, espera toda la página (y los activos) cargar (debe cambiar eso a domready)
los archivos 22-32 son cargados por esas dos bibliotecas, nuevamente después de que estén completamente cargados