Memorizzazione nella cache utilizzando wget

8

Uso drupal 7. Dopo aver svuotato la cache, utilizzo wget in questo modo per memorizzare nuovamente tutte le pagine nella cache.

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

Dopo aver fatto ciò, controllo nel database la tabella cache_page e tutte le pagine sembrano essere lì. Tuttavia, se visito qualsiasi pagina con il browser, ci vuole tempo come se non fosse pre-memorizzato nella cache. Quello che ho notato anche è che dopo aver visitato la pagina nel browser, il tempo di caricamento alla visita successiva è molto veloce come dovrebbe essere.

Quale può essere il problema? Sto usando con successo questo metodo su una pagina Drupal 6 senza problemi. Il registro degli errori non mostra nulla, tranne favicon.ico non esiste.

Il registro di accesso per gli URL è simile al seguente:

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

Non ho effettuato l'accesso

EDIT: ho aggiornato drupal versione 7.14 alla versione 7.19 ma nessuna modifica. Dopo aver esaminato la tabella cache_page ho notato che tutte le pagine visitate utilizzando il browser sono generate per qualche strana ragione con _900 alla fine in questo modo: www.example.com/examplepath_900. Non l'ho notato prima perché i percorsi non si adattano alle celle nelle tabelle del database. Ecco perché le pagine non vengono memorizzate nella cache. Inoltre ho installato una nuova installazione di drupal 7 sullo stesso host in cui la memorizzazione nella cache usando wget funziona come previsto senza problemi. Non ci possono essere problemi anche nei file htaccess o settings. Forse qualche modulo installato può causare questo?

7 caching

— loparr
fonte

Da dove lo fai? Lo stesso server o un altro server?

— mpdonadio

@MPD Uso il terminale cygwin per eseguire wget. Tuttavia, la mia pagina drupal 7 è ospitata da un altro provider che il mio sito drupal 6

— loparr

Puoi visualizzare le intestazioni HTTP? Dopo aver eseguito lo script, controlla le intestazioni e cercane uno come "X-Drupal-Cache: Hit". Ho dimenticato il nome esatto dell'intestazione, però.

— mpdonadio

@MPD Ho cancellato la cache, eseguito lo script, la tabella cache_page mostra tutti i collegamenti ma ho trovato X-Drupal-Cache: MISS nelle intestazioni di tutte le pagine appena visitate.

— Loparr,

Stai testando come utente autenticato? In tal caso, la cache della pagina non verrà colpita.

— David Thomas,

3

Tutti i browser moderni inviano alcune intestazioni Accept-Encoding ~ 'gzip', quindi le voci memorizzate nella cache non verranno utilizzate se il tuo spider non usa questa (un back-end decente che genera risposte gzip aggiunge un diverso: header Accept-Encoding). Puoi anche esaminare l'opzione --mirror di wget che potrebbe aiutarti qui.

— webkenny
fonte

Se webkenny dice qualcosa sulla performance di Drupal, suppongo sia vero. +1.

— Letharion,

1

Per core, l'intestazione gzip non dovrebbe importare. drupal_serve_page_from_cache ()

— mikeytown2

3

Il consiglio di Kenny è solido. Un'altra idea è che potresti avere diverse risorse che vengono memorizzate nella cache nel browser al primo caricamento e quindi non al secondo. Invece di eseguire il test nello stesso browser, prova a eseguire il test in una finestra di navigazione in incognito di Chrome, chiudendo quella finestra e quindi eseguendo di nuovo. Ciò dovrebbe aiutare a determinare se è la mancanza della cache della pagina Drupal di soddisfare la richiesta (forse a causa dell'idea di Gzip) che è responsabile della lentezza o se è la memorizzazione nella cache dei file che li impedisce di scaricare di nuovo, il che rende più veloce la seconda richiesta.

— greggles
fonte

1

Questo problema è stato causato dal modulo http://drupal.org/project/resp_img dopo l'installazione dell'ultima versione, tutto ok.

— loparr
fonte