Almacenamiento en caché con wget

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?

7 caching

— loparr
fuente

¿De dónde haces esto? ¿El mismo servidor u otro servidor?

— mpdonadio

@MPD Uso el terminal cygwin para ejecutar wget. Sin embargo, mi página de drupal 7 está alojada con otro proveedor que mi sitio de drupal 6

— loparr el

¿Puedes ver los encabezados HTTP? Después de ejecutar el script, verifique los encabezados y busque uno como "X-Drupal-Cache: Hit". Sin embargo, olvido el nombre exacto del encabezado.

— mpdonadio

@MPD Borré el caché, ejecuté el script, la tabla cache_page muestra todos los enlaces, pero encontré X-Drupal-Cache: MISS en los encabezados de todas las páginas visitadas recientemente.

— loparr 01 de

¿Estás probando como usuario autenticado? Si es así, la caché de la página no se verá afectada.

— David Thomas

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í.

— webkenny
fuente

Si webkenny dice algo sobre el rendimiento de Drupal, supongo que es cierto. +1.

— Letharion

Para el núcleo, el encabezado gzip no debería importar. drupal_serve_page_from_cache ()

— mikeytown2

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.

— greggles
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.

— loparr
fuente