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テーブルを調べたところ、ブラウザーを使用してアクセスしたすべてのページは、www.example.com / examplepath_900のように、末尾に_900が付けられた何らかの奇妙な理由で生成されていることに気付きました。パスがデータベーステーブルのセル内に収まらないため、これに気づきませんでした。そのため、ページはキャッシュされません。また、wgetを使用したキャッシングが問題なく期待どおりに機能する同じホストにdrupal 7の新規インストールをセットアップしました。htaccessや設定ファイルにも問題はありません。インストールされているモジュールが原因である可能性がありますか？

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

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

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