web-dev-qa-db-ja.com

wgetを使用したキャッシュ

drupal 7.を使用します。キャッシュをクリアした後、このようにwgetを使用してすべてのページをキャッシュします。

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

完了したら、データベースのcache_pageテーブルをチェックインします。すべてのページがそこにあるようです。しかし、ブラウザでページにアクセスすると、事前にキャッシュされていないかのように時間がかかります。私が気づいたのは、ブラウザでページにアクセスした後、次のアクセスでの読み込み時間が予想どおりに非常に速いことです。

問題は何でしょうか？私はこの方法をDrupal 6ページで問題なく使用しています。エラーログにはfavicon.icoが存在しないことのみが示されています。

URLのアクセスログは次のようになります。

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）"

ログインしていません

編集：私はdrupal 7.14から7.19バージョンに変更しましたが、変更はありません。cache_pageテーブルを調べた後、ブラウザを使用してアクセスしたすべてのページは、次のように末尾に_900がある奇妙な理由で生成されていることに気付きました：www .example.com/examplepath_900。パスがデータベーステーブルのセル内に収まらないため、以前は気がつきませんでした。そのため、ページがキャッシュされません。また、drupal wgetを使用したキャッシングが問題なく期待どおりに機能する同じホスト上で7。htaccessまたは設定ファイルにも問題がない可能性があります。インストールされているモジュールが原因の可能性がありますか？

7caching
8
loparr

この問題は、モジュール http://drupal.org/project/resp_img が原因で発生しました。最新バージョンをインストールした後、すべて正常です。

1
loparr

最新のブラウザはすべてAccept-Encoding〜 'gzip'ヘッダーを送信するため、スパイダーがこれを使用しない場合、キャッシュされたエントリは使用されません（適切なバックエンドでgzip圧縮された応答を生成すると、さまざまなAccept-Encodingヘッダーが追加されます）。ここで役立つwgetの--mirrorオプションを調べることもできます。

3
webkenny

ケニーのアドバイスはしっかりしています。もう1つのアイデアは、最初のロードで2番目のロードではなくブラウザにキャッシュされる複数のアセットがある可能性があるということです。同じブラウザーでテストを実行する代わりに、Chromeシークレットウィンドウでテストを実行し、そのウィンドウを閉じてから、もう一度実行してみてください。これは、低速化の原因がDrupalページキャッシュのリクエストの実行の失敗（Gzipのアイデアが原因である可能性がある）であるか、それともファイルのブラウザキャッシュが原因でファイルを再度ダウンロードできないかを判断するのに役立ちます。 2番目のリクエストを高速化します。

3
greggles