Bộ nhớ đệm sử dụng wget

Tôi sử dụng drupal 7. Sau khi xóa bộ nhớ cache, tôi sử dụng wget như thế này để lưu lại tất cả các trang.

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

Sau khi hoàn thành, tôi kiểm tra cơ sở dữ liệu bảng cache_page và tất cả các trang dường như ở đó. Tuy nhiên, nếu tôi truy cập bất kỳ trang nào với trình duyệt, sẽ mất thời gian như thể nó không được lưu trước. Điều tôi cũng nhận thấy là sau khi truy cập trang trên trình duyệt, thời gian tải vào lần truy cập tiếp theo rất nhanh.

các vấn đề có thể là gì? Tôi đang sử dụng thành công phương pháp này trên trang 6 Drupal mà không gặp vấn đề gì. Nhật ký lỗi không hiển thị gì ngoại trừ favicon.ico không tồn tại.

Nhật ký truy cập cho các URL trông như sau:

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

Tôi chưa đăng nhập

EDIT: Tôi đã cập nhật phiên bản drupal 7.14 lên 7.19 nhưng không thay đổi. Sau khi xem xét bảng cache_page, tôi nhận thấy rằng tất cả các trang được truy cập bằng trình duyệt được tạo vì một số lý do lạ với _900 ở cuối như thế này: www.example.com/examplepath_900. Tôi đã không nhận thấy điều đó trước đây vì các đường dẫn không vừa trong các ô trong các bảng cơ sở dữ liệu. Vì vậy, đó là lý do tại sao các trang không được lưu trữ. Ngoài ra, tôi thiết lập cài đặt mới của drupal 7 trên cùng một máy chủ nơi bộ nhớ đệm sử dụng wget hoạt động như mong đợi mà không gặp vấn đề gì. Không thể có vấn đề trong các tập tin htaccess hoặc cài đặt. Có lẽ một số mô-đun cài đặt có thể gây ra điều này?

Tất cả các trình duyệt hiện đại đều gửi một số tiêu đề Chấp nhận mã hóa ~ 'gzip', vì vậy các mục được lưu trong bộ nhớ cache sẽ không được sử dụng nếu con nhện của bạn không sử dụng tiêu đề này (một phản hồi được tạo ra ở mặt sau được mã hóa bổ sung thêm một tiêu đề khác nhau: Chấp nhận mã hóa). Bạn cũng có thể xem xét tùy chọn --mirror của wget có thể hỗ trợ ở đây.

Lời khuyên của Kenny là vững chắc. Một ý tưởng khác là bạn có thể có một số tài sản đang được lưu trong bộ nhớ cache trong trình duyệt ở lần tải đầu tiên và sau đó không phải là tài sản thứ hai. Thay vì thực hiện kiểm tra trong cùng một trình duyệt, hãy thử thực hiện kiểm tra trong cửa sổ Ẩn danh Chrome, đóng cửa sổ đó và sau đó thực hiện lại. Điều đó sẽ giúp xác định xem đó có phải là lỗi của bộ đệm trang Drupal không thực hiện được yêu cầu (có thể do ý tưởng Gzip) chịu trách nhiệm cho sự chậm chạp hoặc nếu đó là bộ nhớ cache của trình duyệt khiến chúng không tải xuống nữa khiến yêu cầu thứ hai nhanh hơn.

Sự cố này là do mô-đun http://drupal.org/project/resp_img gây ra sau khi cài đặt phiên bản mới nhất, mọi thứ đều ổn.