Кеширование с помощью wget

8

Я использую 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 7 на тот же хост, где кеширование с помощью wget работает, как и ожидалось, без проблем. Также не может быть проблем в файлах htaccess или settings. Может быть, какой-то установленный модуль может вызвать это?

7 caching loparr
источник
Откуда ты это делаешь? Тот же сервер или другой сервер?
mpdonadio
@MPD Я использую терминал cygwin для запуска wget. Тем не менее, моя страница на drupal 7 размещена у другого провайдера, как и мой сайт на drupal 6
loparr
Можете ли вы просмотреть заголовки HTTP? После запуска сценария проверьте заголовки и найдите один из них, например «X-Drupal-Cache: Hit». Я забыл точное название заголовка, хотя.
mpdonadio
@MPD Я очистил кеш, запустил скрипт, таблица cache_page показывает все ссылки, но я нашел X-Drupal-Cache: MISS в заголовках всех вновь посещаемых страниц.
loparr
Вы тестируете как аутентифицированный пользователь? Если это так, кэш страницы не будет поврежден.
Дэвид Томас

Ответы:

3

Все современные браузеры отправляют некоторый заголовок Accept-Encoding ~ 'gzip', поэтому кэшированные записи не будут использоваться, если ваш паук не использует этот (приличный бэкэнд, генерирующий gzipped ответы, добавляет переменную: заголовок Accept-Encoding). Вы также можете посмотреть опцию --mirror в wget, которая может помочь здесь.

webkenny
источник
Если webkenny что-то говорит о производительности Drupal, я предполагаю, что это правда. +1.
Летарион
1
Для ядра заголовок gzip не должен иметь значения. drupal_serve_page_from_cache ()
mikeytown2
3

Совет Кенни твердый. Еще одна идея заключается в том, что у вас может быть несколько ресурсов, которые кэшируются в браузере при первой загрузке, а затем не во второй. Вместо того, чтобы выполнять тест в том же браузере, попробуйте выполнить тест в окне Chrome Incognito, закройте это окно и повторите его. Это должно помочь определить, является ли неспособность кеша страницы Drupal выполнить запрос (возможно, из-за идеи Gzip), который ответственен за медлительность, или это кеширование файлов браузером, заставляющее их не загружаться снова, что делает второй запрос быстрее.

greggles
источник