Take the 2-minute tour ×
Drupal Answers is a question and answer site for Drupal developers and administrators. It's 100% free, no registration required.

I use drupal 7. After clearing the cache, I use wget like this to cache all pages back.

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

After it is done, I check in database the cache_page table, and all pages seems to be there. However, if I visit any page with the browser, it takes time as if it was not pre-cached. What I noticed as well is that after visiting the page in browser, the loading time on next visit is very fast as it should be.

What can the problem be? I am successfully using this method on a Drupal 6 page with no problems. Error log shows nothing except favicon.ico does not exist.

The access log for URLs looks like the following:

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

I am NOT logged in

EDIT: I updated drupal 7.14 to 7.19 version but no change. After looking into cache_page table I noticed that all pages visited using browser are generated for some strange reason with _900 at the end like this: www.example.com/examplepath_900. I did not noticed it before because the paths don't fit inside the cells in database tables. So that is why pages are not cached. Also I set up fresh installation of drupal 7 on the same host where caching using wget works as expected with no problems. There can not be problem in htaccess or settings files as well. Maybe some installed module can cause this?

share|improve this question
    
Where are you doing this from? The same server, or another server? –  MPD Jan 1 '13 at 15:42
    
@MPD I use cygwin terminal to run wget. However, my drupal 7 page is hosted with another provider that my drupal 6 site –  loparr Jan 1 '13 at 16:13
    
Can you view HTTP headers? After you run the script, check the headers and look for one like "X-Drupal-Cache: Hit". I forget the exact header name, though. –  MPD Jan 1 '13 at 16:45
    
@MPD I cleared the cache, ran the script,cache_page table shows all links but I found X-Drupal-Cache:MISS in headers of all newly visited pages. –  loparr Jan 1 '13 at 17:13
    
Are you testing as an authenticated user? If so, the page cache won't be hit. –  David Thomas Jan 1 '13 at 23:17
show 6 more comments

3 Answers 3

All modern browsers send some Accept-Encoding ~ 'gzip' header, so cached entries will not be used if your spider doesn't use this one (a decent back-end generating gzipped responses adds a vary: Accept-Encoding header). You may also look into the --mirror option of wget which could assist here.

share|improve this answer
    
If webkenny says something about Drupal performance, I'm assuming it's true. +1. –  Letharion Jan 11 '13 at 10:47
1  
For core, the gzip header shouldn't matter. drupal_serve_page_from_cache() –  mikeytown2 Jan 11 '13 at 20:27
add comment

Kenny's advice is solid. One other idea is that you may have several assets that are being cached in the browser on the first load and then not the second. Instead of doing the test in the same browser, try doing the test in a Chrome Incognito window, closing that window, and then doing it again. That should help determine if it is the Drupal page cache's failure to fulfill the request (maybe because of the Gzip idea) that is responsible for slowness or if it is browser caching of files causing them not to download again which makes the second request faster.

share|improve this answer
add comment
up vote 1 down vote accepted

This issue was caused by module http://drupal.org/project/resp_img after installing the latest version, everything is ok.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.