Pre-riscaldamento del Magento Enterprise Pagina intera cache

Question

I vantaggi di prestazioni della cache pagina intera in Magento Enterprise sono abbastanza noto. Ciò che non può essere così ben noto è che per il beneficio completo di questo per essere realizzato, deve essere completamente popolato e caldo, in particolare su grandi insiemi di prodotto per i quali non si dispone di poche pagine rendendo così l'uso del traffico organico al Prime abbastanza veloce.

Magento include un built-in cronjob per eseguire la scansione del sito e riscaldare la FPC prime ore del mattino.

che ho visto e sentito parlare di problemi causati da lavori del mattino impiegando troppo tempo per correre, bloccando altri lavori da corsa, e vorrei sapere quello che gli altri usano o suggerirebbe essere utilizzati per fare questo. Un paio di idee che ho sono:

• Mettere insieme uno script di shell per eseguire la scansione ogni pagina nel file sitemap generata.
• Utilizzare una voce crontab separata e uno script PHP breve per bootstrap Magento ed eseguire direttamente il processo cingolato.

Tutti i pensieri e / o esperienza su questo è il benvenuto!

Answer 1

Si potrebbe usare assedio in combinazione con il file sitemap.xml, come MageSpeedTest fa.

#categories
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
#products
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1.0 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' >> urls.txt

Quindi eseguire

siege -i -c 1 -t 7200s -f urls.txt

^{Contenuti provenienti da qui .}

Answer 2

Noi semplicemente non - a tutti. Mai. Diremo questo più e più volte, ma

Caching! = Performance

Il tuo sito deve per essere veloce senza l'aggiunta di FPC (o vernice per questo fatto). C'è sempre sarà un momento in cui il contenuto non è innescato (lo scenario di cui sopra).

In un negozio di scarico, i tempi di caricamento delle pagine con FPC non dovrebbe essere molto più impressionante rispetto ai non-FPC; Magento è tranquillamente in grado di tempi di caricamento della pagina < 400ms su cache standard di (sulle pagine categoria / prodotti / ricerca). FPC che porterà fino a < 80ms -. Ma viene con avvertimenti

1. Immagine / informazioni sui prezzi sono scaduti fino invalidazione o TTL scadenza

2. I nuovi elementi / di ricerca più pertinenti sono scaduti fino invalidazione o TTL scadenza

   ecc.

Perché affidamento su FPC (o vernice) è una cattiva idea

Se stai cercando di garantire continuamente cache sono innescato manualmente, c'è probabilmente un paio di motivi

1. Non hai abbastanza calpestio naturale per mantenere le cache innescato (vedi 'Dove FPC è utile')
2. Il tuo sito è troppo lento senza di loro

Non si può cache di tutto

Se si prende un negozio con solo 5 categorie, annidato 2 livelli di profondità, 5 attributi filtrabili, 5 opzioni di attributi ciascuno e 1000 prodotti; che è molto di combinazioni possibili.

25 opzioni tra cui scegliere, sceglierne uno fino a 5 volte di fila - io non sono un esperto di statistica , ma mi rendo conto che è ... (supponendo che il numero di opzioni di attributi non diminuisce completamente)

25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5  possible URLs on the fifth selection

5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)

Ok, quanto sopra non è uno scenario probabile, come immagino, entro 3 scatti - il numero di prodotti disponibili sarebbe diminuito a sufficienza per il cliente di trovare il loro prodotto. Quindi, anche se si trattasse di ...

25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection

5^3 = 125 possible URL combinations 

Poi volte che entro 5 categorie, che è di 625 URL. In questa fase, stiamo parlando di un piccolo catalogo, e ignorando completamente tutti gli URL dei prodotti.

Stiamo, inoltre, non factoring nel senso che se tu avessi categorie nidificate con is_anchor su, la sua intenzione di aumentare in modo esponenziale.

Quindi, per strisciare quel volume di pagine - che hai sia avuto modo di speranza che i tempi di caricamento delle pagine sono belle e basso per cominciare, in modo che si tratta di un processo leggero rapido (vanificando così lo scopo della scansione) - o di avere abbastanza tempo per il completamento prima della scadenza TTL.

Se le pagine avuto un tempo di caricamento della pagina di 0.4s e si aveva una CPU a 8 core - allora ...

625 * 0.4 = 250 / 8 = 31 seconds

0,5 minuti, non male - ma lascia immaginare avuto tempi di caricamento pagina 2s

625 * 2 = 1250 / 8 = 156 seconds

Ma se si ha il massimo possibile scenario

3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes

Ecco, questo è il vostro server di produzione, sotto il carico della CPU al 100% per 15 minuti. Si potrebbe ridurre la marcia lenta in proporzione al TTL che si desidera.

Quindi, se si desidera che il contenuto di avere un TTL 3600s, la ricerca per indicizzazione potrebbe essere 4 volte più lento - vale a dire. solo il 25% della CPU dedicata alla scansione. Questo è un sacco di risorse solo per mantenere il contenuto categoria innescato - non abbiamo nemmeno presi in prodotti, termini o punti di vista negozio aggiuntive Cerca in questa fase

In realtà, solo guardando la vastità delle combinazioni nella tabella catalog_url_rewrites (che non è nemmeno il factoring nei parametri della navigazione a strati) darà un'idea di quanti URL si potrebbe finire dover strisciare.

Ogni negozio sarà certamente diverso, ma quello che sto cercando di colpire a casa è che la scansione del sito per primo FPC non è pratico. Basta assicurare il vostro negozio è veloce per iniziare con .

Dove FPC è utile

Qualora le prestazioni di FPC entrano in gioco è su un negozio pesantemente caricato - dove si ha veramente alti livelli di traffico e le cache sono naturalmente econtinuamente imbeccato da pura piede cadere da solo.

FPC entra poi in gioco, riducendo le spese generali di infrastruttura sul contenuto comunemente richiesto - riducendo quelle ripetute chiamate al backend Magento.

Così abbiamo scoperto che FPC è grande per distribuire quando hai livelli molto elevati di traffico - di non ridurre il tempo di caricamento pagina -. Ma per ridurre l'utilizzo delle risorse

Chi se ne frega, ho ancora voglia di strisciare

Bene, allora hai due opzioni

1. Crawl da un modello (es. Mappa del sito)
2. Pagina estragga i collegamenti per pagina e strisciare ogni

E ci sono molte utility per fare entrambe queste, questi sono alcuni che conosco

1. mago-perftest
2. HTTrack
3. Nutch
4. Sphider
5. Crawler4j

Utilizzo Mage-Perftest

E 'possibile la scansione del tuo negozio con Mage-Perftest abbastanza facilmente, primo download it

wget http://sys.sonassi.com/mage-perftest          (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386     (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*

Poi definire il processo di scansione utilizzando la mappa del sito Magento (è possibile personalizzare questo facendo una mappa del sito di tutti gli URL, purché gli URL sono avvolti nei tag <loc></loc>). Il seguente comando leggerà tutti gli URL dal file sitemap, quindi crawl (solo PHP) gli URL nel corso di 1440 minuti (1 giorno). Se il server supera il 20% della CPU o un carico medio di 2 -. La ricerca per indicizzazione per mettere in pausa temporaneamente

./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2  

Se si dispone di 1000 URL, strisciò 1 giorno, che sarà circa. 1 richiesta ogni 86 secondi (s) ~ bersaglio di 0,011 RPS

Answer 3

Vi risparmio la mia piena rant per un post sul blog uno di questi giorni, ma nel frattempo hanno un picco a mio piccolo nascondiglio più caldo wfpc .

prestazioni Test

È possibile verificare le prestazioni del vostro sito Magento

./wfpc -t http://mymagentosite.com/sitemap.xml

Finished testing your Magento site performance
Total download time (in seconds)   : 5.0269110202789
Total download time (formatted)    : 0:0:5.026
Average page time (in milliseconds): 502.69110202789

FPC riscaldamento

E si può riscaldare la FPC, che colpirà ogni URL in sitemap.xml.

./wfpc -w http://mymagentosite.com/sitemap.xml

Si può anche mettere un ritardo tra le richieste, se vi piace, ecco un ritardo di 1 secondo tra le richieste.

./wfpc -w -d=1 http://mymagentosite.com/sitemap.xml

La modalità di test colpisce solo 10 URL in modo casuale, quindi una volta che hai riscaldato il tuo FPC, è possibile eseguire la modalità di test per scoprire quanto di una differenza del FPC fa!

Pensieri

Personalmente, penso che un caldo senso ... In un piccolo sito con circa 40 pagine, il tempo di download è tagliato all'incirca a metà dal FPC. Su un sito di grandi dimensioni con quasi 40.000 prodotti che utilizzano Lesti_FPC con APCu come backend, sto usando un po 'più di 200 MB per la cache, che francamente è nulla sul server di produzione da 8 GB.