Armazenando em cache usando o wget

8

Uso o drupal 7. Depois de limpar o cache, uso o wget assim para armazenar em cache todas as páginas de volta.

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

Depois de feito, eu verifico no banco de dados a tabela cache_page, e todas as páginas parecem estar lá. No entanto, se eu visitar qualquer página do navegador, isso leva tempo como se não tivesse sido pré-armazenado em cache. O que notei também é que, depois de visitar a página no navegador, o tempo de carregamento na próxima visita é muito rápido, como deveria ser.

Qual pode ser o problema? Estou usando esse método com êxito em uma página do Drupal 6 sem problemas. O log de erros não mostra nada, exceto o favicon.ico não existe.

O log de acesso para URLs é semelhante ao seguinte:

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

Eu não estou logado

EDIT: Eu atualizei a versão drupal 7.14 para 7.19, mas nenhuma alteração. Depois de examinar a tabela cache_page, notei que todas as páginas visitadas usando o navegador são geradas por algum motivo estranho com _900 no final, assim: www.example.com/examplepath_900. Eu não havia notado isso antes porque os caminhos não cabem dentro das células nas tabelas do banco de dados. É por isso que as páginas não são armazenadas em cache. Também configurei uma instalação nova do drupal 7 no mesmo host em que o cache usando o wget funciona conforme o esperado, sem problemas. Não pode haver problema no htaccess ou nos arquivos de configurações também. Talvez algum módulo instalado possa causar isso?

7 caching loparr
fonte
De onde você está fazendo isso? O mesmo servidor ou outro servidor?
mpdonadio
@MPD Eu uso o terminal cygwin para executar o wget. No entanto, o meu Drupal 7 página está hospedada com outro provedor que meu site Drupal 6
loparr
Você pode visualizar os cabeçalhos HTTP? Depois de executar o script, verifique os cabeçalhos e procure um como "X-Drupal-Cache: Hit". Mas eu esqueço o nome exato do cabeçalho.
mpdonadio
@MPD Limpei o cache, executei o script, a tabela cache_page mostra todos os links, mas encontrei o X-Drupal-Cache: MISS nos cabeçalhos de todas as páginas recém-visitadas.
Loparr 01/01
Você está testando como um usuário autenticado? Nesse caso, o cache da página não será atingido.
David Thomas

Respostas:

3

Todos os navegadores modernos enviam algum cabeçalho Accept-Encoding ~ 'gzip', para que as entradas em cache não sejam usadas se o seu spider não o usar (um back-end decente que gera respostas compactadas em gzip adiciona um cabeçalho de variação: Accept-Encoding). Você também pode procurar na opção --mirror do wget, que pode ajudar aqui.

webkenny
fonte
Se webkenny diz algo sobre o desempenho do Drupal, suponho que seja verdade. +1.
Letharion
11
Para o core, o cabeçalho gzip não deve importar. drupal_serve_page_from_cache ()
mikeytown2
3

O conselho de Kenny é sólido. Uma outra idéia é que você pode ter vários ativos que estão sendo armazenados em cache no navegador no primeiro carregamento e depois no segundo. Em vez de fazer o teste no mesmo navegador, tente fazer o teste em uma janela anônima do Chrome, fechando a janela e, em seguida, faça-o novamente. Isso deve ajudar a determinar se a falha do cache da página Drupal em atender à solicitação (talvez por causa da ideia do Gzip) é responsável pela lentidão ou se o cache de arquivos do navegador faz com que eles não façam o download novamente, o que torna a segunda solicitação mais rápida.

greggles
fonte