Uso drupal 7. Después de borrar el caché, uso wget como este para almacenar en caché todas las páginas.
wget --quiet http://xxx.xxx/sitemap.xml --output-document - | egrep -o "http://xxx.xxx[^<]+" | wget -q --delete-after -i -
Una vez hecho esto, verifico en la base de datos la tabla cache_page, y todas las páginas parecen estar allí. Sin embargo, si visito cualquier página con el navegador, lleva tiempo como si no estuviera previamente almacenada en caché. Lo que noté también es que después de visitar la página en el navegador, el tiempo de carga en la próxima visita es muy rápido como debería ser.
Cuál puede ser el problema? Estoy utilizando este método con éxito en una página de Drupal 6 sin problemas. El registro de errores no muestra nada excepto que favicon.ico no existe.
El registro de acceso para las URL tiene el siguiente aspecto:
www.xxx.sk 11.116.206.232 - - [01 / ene / 2013: 18: 09: 12 +0100] "GET / myurl HTTP / 1.1" 200 31532 "-" "Wget / 1.13.4 (cygwin)"
NO estoy conectado
EDITAR: Actualicé la versión de drupal 7.14 a 7.19 pero no cambié. Después de mirar la tabla cache_page, noté que todas las páginas visitadas usando el navegador se generan por alguna extraña razón con _900 al final de esta manera: www.example.com/examplepath_900. No lo noté antes porque las rutas no caben dentro de las celdas en las tablas de la base de datos. Por eso las páginas no se almacenan en caché. También configuré una nueva instalación de drupal 7 en el mismo host donde el almacenamiento en caché usando wget funciona como se esperaba sin problemas. No puede haber problemas en htaccess o archivos de configuración también. ¿Quizás algún módulo instalado puede causar esto?
Respuestas:
Todos los navegadores modernos envían un encabezado Accept-Encoding ~ 'gzip', por lo que las entradas en caché no se usarán si su araña no usa este (un back-end decente que genera respuestas gzipped agrega una variación: encabezado Accept-Encoding). También puede buscar en la opción --mirror de wget que podría ayudar aquí.
fuente
El consejo de Kenny es sólido. Otra idea es que puede tener varios activos que se almacenan en caché en el navegador en la primera carga y luego no en la segunda. En lugar de hacer la prueba en el mismo navegador, intente hacer la prueba en una ventana de incógnito de Chrome, cierre esa ventana y luego vuelva a hacerlo. Eso debería ayudar a determinar si es la falla de la caché de la página Drupal para cumplir con la solicitud (tal vez debido a la idea de Gzip) la responsable de la lentitud o si el almacenamiento en caché de los archivos del navegador hace que no se vuelvan a descargar, lo que hace que la segunda solicitud sea más rápida.
fuente
Este problema fue causado por el módulo http://drupal.org/project/resp_img después de instalar la última versión, todo está bien.
fuente