Mise en cache à l'aide de wget

J'utilise drupal 7. Après avoir effacé le cache, j'utilise wget comme ceci pour mettre en cache toutes les pages.

wget --quiet http://xxx.xxx/sitemap.xml --output-document - | egrep -o "http://xxx.xxx[^<]+" | wget -q --delete-after -i -

Après cela, je vérifie dans la base de données la table cache_page, et toutes les pages semblent être là. Cependant, si je visite une page avec le navigateur, cela prend du temps comme si elle n'était pas pré-mise en cache. Ce que j'ai également remarqué, c'est qu'après avoir visité la page dans le navigateur, le temps de chargement lors de la prochaine visite est très rapide comme il se doit.

Quel peut être le problème? J'utilise avec succès cette méthode sur une page Drupal 6 sans problème. Le journal des erreurs ne montre rien sauf que favicon.ico n'existe pas.

Le journal d'accès pour les URL ressemble à ceci:

www.xxx.sk 11.116.206.232 - - [01 / Jan / 2013: 18: 09: 12 +0100] "GET / myurl HTTP / 1.1" 200 31532 "-" "Wget / 1.13.4 (cygwin)"

Je ne suis pas connecté

EDIT: J'ai mis à jour la version drupal 7.14 vers 7.19 mais aucun changement. Après avoir examiné la table cache_page, j'ai remarqué que toutes les pages visitées à l'aide du navigateur sont générées pour une raison étrange avec _900 à la fin comme ceci: www.example.com/examplepath_900. Je ne l'avais pas remarqué auparavant car les chemins ne rentrent pas dans les cellules des tables de base de données. C'est pourquoi les pages ne sont pas mises en cache. J'ai également mis en place une nouvelle installation de drupal 7 sur le même hôte où la mise en cache à l'aide de wget fonctionne comme prévu sans problème. Il ne peut pas y avoir de problème dans htaccess ou dans les fichiers de paramètres. Peut-être qu'un module installé peut provoquer cela?

Tous les navigateurs modernes envoient un en-tête Accept-Encoding ~ 'gzip', donc les entrées mises en cache ne seront pas utilisées si votre araignée n'utilise pas celle-ci (un back-end décent générant des réponses gzippées ajoute une variable: en-tête Accept-Encoding). Vous pouvez également examiner l'option --mirror de wget qui pourrait vous aider ici.

Les conseils de Kenny sont solides. Une autre idée est que vous pouvez avoir plusieurs actifs qui sont mis en cache dans le navigateur au premier chargement et non au second. Au lieu de faire le test dans le même navigateur, essayez de faire le test dans une fenêtre Chrome Incognito, fermez cette fenêtre, puis recommencez. Cela devrait aider à déterminer si c'est l'échec du cache de page Drupal pour répondre à la demande (peut-être à cause de l'idée de Gzip) qui est responsable de la lenteur ou si c'est la mise en cache par le navigateur des fichiers qui les empêche de télécharger à nouveau, ce qui accélère la deuxième demande.

Ce problème est dû au module http://drupal.org/project/resp_img après l'installation de la dernière version, tout va bien.