Mise en cache à l'aide de wget

8

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?

7 caching loparr
la source
D'où faites-vous cela? Le même serveur, ou un autre serveur?
mpdonadio
@MPD J'utilise le terminal cygwin pour exécuter wget. Cependant, ma page drupal 7 est hébergée chez un autre fournisseur que mon site drupal 6
loparr
Pouvez-vous afficher les en-têtes HTTP? Après avoir exécuté le script, vérifiez les en-têtes et recherchez-en un comme "X-Drupal-Cache: Hit". Mais j'oublie le nom exact de l'en-tête.
mpdonadio
@MPD J'ai effacé le cache, exécuté le script, le tableau cache_page affiche tous les liens mais j'ai trouvé X-Drupal-Cache: MISS dans les en-têtes de toutes les pages récemment visitées.
loparr
Testez-vous en tant qu'utilisateur authentifié? Si c'est le cas, le cache de page ne sera pas atteint.
David Thomas

Réponses:

3

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.

webkenny
la source
Si webkenny dit quelque chose sur les performances de Drupal, je suppose que c'est vrai. +1.
Letharion
1
Pour le noyau, l'en-tête gzip ne devrait pas avoir d'importance. drupal_serve_page_from_cache ()
mikeytown2
3

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.

greggles
la source