Las miniaturas en caché generadas por PHP se cargan lentamente

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

Pregunta Parte B ▉ (100 recompensas, otorgado)
El nuevo enfoque ahora era resolver el problema que tenían las 6 imágenes jpg, que están causando la mayor parte del retraso de carga. Estas 6 imágenes son miniaturas generadas por PHP, pequeñas y de solo 3 ~ 5 kb, pero cargando relativamente muy lentamente. Observe el " tiempo hasta el primer byte " en los diversos gráficos. El problema permaneció sin resolver, pero James recibió una recompensa, que corrigió el error de encabezado que RedBot subrayó : "Una solicitud condicional If-Modified-Since devolvió el contenido completo sin cambios". .

Pregunta Parte C ▉ (mi última recompensa: 250 puntos)
Desafortunadamente, incluso después de que se solucionó el error de encabezado REdbot.org, el retraso causado por las imágenes generadas por PHP permaneció intacto. ¿En qué demonios están pensando estas minúsculas miniaturas de 3 ~ 5Kb? 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 una posible respuesta, ya que estoy atrapado en este problema de cuello de botella desde hace ya siete meses. Gracias 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ó 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". Es inofensivo y, a menudo, más feliz.]

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

Dominios Paralelos Agrupados | http://webpagetest.org

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

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

Cascada GTmetrix | http://gtmetrix.com

Primero, el uso de 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 difundir las solicitudes.

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

Específicamente, se puede hacer referencia a las bibliotecas jQuery y jQuery UI más recientes 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 e imágenes del Google CDN .

Con el hospedaje de jQuery optimizado, también se debe combinar awmlib2.jsy tooltiplib.jsen un solo archivo.

Si aborda esas cosas, debería ver una mejora significativa.

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

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 utilizado para generar las Miniaturas debe verificar lo siguiente:

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

Si alguno de estos es falso, la miniatura debe generarse y devolverse sin importar qué. Si ambas son ciertas, entonces se debe hacer la siguiente verificación:

1. ¿Hay un encabezado HTTP_IF_MODIFIED_SINCE
2. ¿La última hora modificada de la versión en caché es la misma que HTTP_IF_MODIFIED_SINCE

Si alguno de estos es falso, se debe devolver la miniatura en caché.

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

En cuanto a GZipping, me han informado que no hay necesidad de GZip, así que ignore 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 debe verificar el encabezado HTTP_IF_MODIFIED_SINCE y reaccionar ante él. Simplemente configurando 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

Wow, es difícil explicar las 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 primero por completo antes de cargar cualquier contenido adicional
• los archivos 20 y 21 son tal vez (no sé, porque no conozco su código) bibliotecas cargadas por all.js (11), pero para que 11 se ejecute, espera la página completa (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 cargadas

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

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

Dados los diagramas, esto podría explicar un gran éxito en el rendimiento.

En una nota al margen, existe esta herramienta genial que podría ayudarlo a resolver las cosas dependiendo de su pedido de carga de recursos.

Intente ejecutar las pruebas Y! Slow y Page Speed ​​en su sitio / página, y siga las pautas para solucionar posibles cuellos de botella de rendimiento. Debería obtener enormes ganancias de rendimiento una vez que obtenga una puntuación más alta en Y! Slow o Page Speed

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

¿Entonces su script PHP está generando las miniaturas en cada carga de página? En primer lugar, si las imágenes que se muestran en miniatura no cambian con tanta frecuencia, ¿podría configurar un caché para que no tengan que analizarse cada vez que se carga la página? En segundo lugar, ¿su script PHP está usando algo como imagecopyresampled()crear las miniaturas? Esa es una disminución no trivial y el script PHP no devolverá nada hasta que termine de reducir las cosas. En imagecopymerged()cambio, usar reducirá la calidad de la imagen, pero acelerará el proceso. ¿Y cuánta reducción estás haciendo? ¿Estas miniaturas son del 5% del tamaño de la imagen original o del 50%? Es probable que un mayor tamaño de la imagen original conduzca a una desaceleración ya que el script PHP tiene que guardar la imagen original en la memoria antes de que pueda reducirla y generar una miniatura más pequeña.

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

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

Dado que el control de caché es "public, max-age = 14515200", los encabezados arbitrarios de última modificación podrían causar problemas después de 168 días.

De todos modos, esta no es la verdadera razón de los retrasos.

Debe verificar qué hace su generador de miniaturas cuando la miniatura ya existe y qué podría consumir tanto tiempo revisando y entregando la imagen.

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

Tal vez todo usa un marco o se conecta a alguna base de datos por 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 ...

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

Cree una regla de reescritura para su servidor web que sirva la imagen directamente si se encuentra en el sistema de archivos. Si no es así, redirige a tu script PHP para generar la imagen. Cuando edite la imagen, cambie el nombre del 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 no funciona al menos, ahora no tendrá nada que ver con la forma en que se crean y verifican las imágenes.

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

PHP bloquea los datos de sesión para cada script que se ejecuta, desde el momento en que comienza el manejo de la sesión, hasta el momento en que finaliza el script, o cuando se llama a session_write_close (). Esto efectivamente serializa las cosas. Echa un vistazo a la página PHP sobre sesiones, especialmente los comentarios, como este .

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

Los datos de la sesión generalmente se almacenan después de que su script finalizó 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 un script puede operar en una sesión en cualquier momento. Cuando use 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 realicen todos los cambios en las variables de sesión.

Como dije, no sé qué está haciendo su código, pero esos gráficos parecen extrañamente sospechosos. Tuve un problema similar cuando codifiqué una función de servicio de archivos multiparte y tuve el mismo problema. Al servir un archivo de gran tamaño, no pude hacer que funcionara la funcionalidad multiparte ni abrí otra página hasta que se completó la descarga. Llamar session_write_close()solucionó mis dos problemas.

¿Has intentado reemplazar las thumnails generadas por php por imágenes regulares para ver si hay alguna diferencia? El problema podría estar relacionado: un error en su código php que conduce a una regeneración de la miniatura en cada invocación del servidor, un retraso en su código (¿dormir ()?) Asociado con un problema de reloj, un problema de disco duro que causa una muy mala condición de carrera ya que todas las miniaturas se cargan / generan al mismo tiempo.

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

http://i.tinysrc.mobi/ [altura] / [ancho] /http://domain.tld/path_to_img.jpg

[anchura] (opcional): - Este es un ancho en píxeles (que anula el tamaño adaptable o familiar). Si tiene el prefijo '-' o 'x', se 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 tener como prefijo '-' o 'x'.

Puedes consultar el resumen de la API aquí

Preguntas más frecuentes

¿Cuánto 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 ofrece alta disponibilidad en todo el mundo. Debería ser suficiente para todas sus necesidades.

Que tan rapido es

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

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

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

En primer lugar, debe manejar las If-Modified-Sincesolicitudes y de manera adecuada, como dijo James. Ese error indica que: "Cuando le pregunto a su servidor si esa imagen se modificó desde la última vez, envía la imagen completa en lugar de un simple sí / no".

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

1. ¿Has considerado perfilarlo? Puede tener algunos problemas.
2. En combinación con el problema anterior, su script puede ejecutarse 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 cualquier otra solicitud. ¿Ha verificado que el script genera 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 el servidor puede sobrescribirlos. Y está expuesto al abuso, ya que cualquiera que envíe algunos encabezados de solicitud sin caché hará que su generador de miniaturas se ejecute continuamente (y aumente las cargas). Entonces, 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ías nada .htaccesssi tu servidor está configurado correctamente.

Aparte de estos, puede aplicar algunas de las brillantes ideas de optimización de las partes de rendimiento de esta pregunta SO 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 de 3k No debería tomar un segundo para cargar, esto es evidente en comparación con otros elementos en los gráficos. Debe intentar detectar el problema antes de optimizar.

¿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 podría encontrarse en este tema .

Con respecto a las miniaturas retrasadas, intente poner una llamada a flush () inmediatamente después de la última llamada al encabezado () en su script de generación de miniaturas. Una vez hecho esto, regenere su gráfico de cascada y vea si el retraso está ahora 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.

Con suerte, el script que maneja las miniaturas debería usar algún tipo de almacenamiento en caché para que cualquier acción que tome en las imágenes que está publicando solo ocurra cuando sea absolutamente necesario. Parece que se está llevando a cabo una operación costosa cada vez que sirve las miniaturas, lo que retrasa cualquier salida (incluidos los encabezados) del script.

La mayor parte del problema lento es que su TTFB (Tiempo hasta el primer byte) es demasiado alto. Es difícil de abordar sin tener que familiarizarse con los archivos de configuración de su servidor, el código y el hardware subyacente, pero puedo ver que es rampante 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 tiempo, 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 back-end, material de servidor, preprocesamiento previo a la salida y protocolo de enlace.

Mida el tiempo de ejecución de su código para encontrar cosas lentas, como consultas lentas de bases de datos, funciones / métodos de entrada y salida de tiempo para encontrar funciones lentas. Si usas php, prueba Firephp . A veces, se ejecutan una o dos consultas lentas 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 consultas puede conducir a algunas buenas ganancias de rendimiento. A 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 de almacenamiento en caché lentas u operaciones de E / S lentas causadas por unidades de disco defectuosas o uso elevado de espacio en disco. Busque usos de memoria y qué se está utilizando y dónde. Ejecute una prueba repetida de prueba de página web de 10 ejecuciones en una sola imagen o archivo utilizando solo la primera vista desde diferentes ubicaciones en todo el mundo y no la misma ubicación. Y lea sus registros de acceso y error, demasiados desarrolladores los ignoran y solo confían en los errores que aparecen en la pantalla. Si su proveedor de alojamiento web tiene soporte, pídales ayuda, si de todos modos no le piden ayuda cortésmente, no le hará daño.

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

¿Es el servidor suyo un servidor bueno / decente? A veces, un mejor servidor puede resolver muchos problemas. Soy fanático de la mentalidad de "el hardware es barato, los programadores son caros ", si tienes la oportunidad y el dinero actualiza un servidor. Y / o use un CDN como maxcdn o cloudflare o similar.

¡Buena suerte!

(PD, no trabajo para ninguna de estas empresas. Además, el enlace de Cloudflare 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 están generados.

NUNCA TRANSMITIR 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 colocar un .htaccess en el directorio de imágenes que redirige a un script php generador solo si falta la imagen de solicitud. (Esto se llama estrategia de caché bajo solicitud).

Hacer eso arreglará la sesión de php, el proxy del navegador, el almacenamiento en caché, ETAGS, lo que sea todo a la vez.

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

Escribí esto hace algún 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 puedes tome el .htaccess como ejemplo solo para probar las cosas (aunque hay mejores formas de configurar el .htaccess que de la forma en 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