it-swarm.com.de

Caching mit wget

Ich verwende drupal 7. Nachdem ich den Cache geleert habe, verwende ich wget wie folgt, um alle Seiten zurückzuspeichern.

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

Nachdem dies erledigt ist, überprüfe ich in der Datenbank die Tabelle cache_page und alle Seiten scheinen dort zu sein. Wenn ich jedoch eine Seite mit dem Browser besuche, dauert es einige Zeit, als wäre sie nicht zwischengespeichert. Was mir auch aufgefallen ist, ist, dass nach dem Besuch der Seite im Browser die Ladezeit beim nächsten Besuch sehr schnell ist, wie sie sein sollte.

Was kann das Problem sein? Ich verwende diese Methode erfolgreich auf einer Drupal 6-Seite ohne Probleme. Das Fehlerprotokoll zeigt nichts an, außer dass favicon.ico nicht existiert.

Das Zugriffsprotokoll für URLs sieht folgendermaßen aus:

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)

Ich bin NICHT eingeloggt

BEARBEITEN: Ich habe die Version drupal 7.14 auf 7.19 aktualisiert, aber keine Änderung vorgenommen. Nachdem ich mir die Tabelle cache_page angesehen hatte, stellte ich fest, dass alle mit dem Browser besuchten Seiten aus irgendeinem seltsamen Grund mit _900 am Ende wie folgt generiert wurden: www.example.com/examplepath_900. Ich habe es vorher nicht bemerkt, weil die Pfade nicht in die Zellen in Datenbanktabellen passen. Deshalb werden Seiten nicht zwischengespeichert. Außerdem habe ich eine Neuinstallation von drupal 7 auf demselben Host eingerichtet, auf dem das Caching mit wget wie erwartet ohne Probleme funktioniert. Es kann auch kein Problem mit htaccess- oder Einstellungsdateien geben. Vielleicht kann ein installiertes Modul dies verursachen?

8
loparr

Dieses Problem wurde durch das Modul http://drupal.org/project/resp_img verursacht. Nach der Installation der neuesten Version ist alles in Ordnung.

1
loparr

Alle modernen Browser senden einen Accept-Encoding ~ 'gzip'-Header, sodass zwischengespeicherte Einträge nicht verwendet werden, wenn Ihre Spinne diesen nicht verwendet (ein anständiges Back-End, das gezippte Antworten generiert, fügt eine Variation hinzu: Accept-Encoding-Header). Sie können sich auch die Option --mirror von wget ansehen, die hier hilfreich sein könnte.

3
webkenny

Kennys Rat ist solide. Eine andere Idee ist, dass Sie möglicherweise mehrere Assets haben, die beim ersten Laden im Browser zwischengespeichert werden und dann nicht beim zweiten. Anstatt den Test im selben Browser durchzuführen, versuchen Sie, den Test in einem Chrome Incognito-Fenster durchzuführen, schließen Sie dieses Fenster und wiederholen Sie ihn dann. Dies sollte helfen, festzustellen, ob der Drupal Seiten-Cache die Anforderung nicht erfüllt (möglicherweise aufgrund der Gzip-Idee), der für die Langsamkeit verantwortlich ist, oder ob das Browser-Caching von Dateien dazu führt, dass sie nicht erneut heruntergeladen werden macht die zweite Anfrage schneller.

3
greggles