Pre-riscaldamento della cache a pagina intera di Magento Enterprise

I vantaggi prestazionali della cache a pagina intera in Magento Enterprise sono abbastanza noti. Ciò che potrebbe non essere così ben noto è che per realizzare appieno il vantaggio di questo, deve essere completamente popolato e caldo, in particolare su grandi set di prodotti in cui non si hanno solo poche pagine e quindi utilizzare il traffico organico per adescalo abbastanza velocemente.

Magento include un cronjob incorporato per eseguire la scansione del sito e riscaldare l'FPC al mattino presto.

Ho visto e sentito parlare di problemi causati da lavori di prima mattina che richiedono troppo tempo per essere eseguiti, bloccando l'esecuzione di altri lavori e vorrei sapere cosa usano gli altri o suggerirebbero di essere usati per farlo. Un paio di idee che ho sono:

Metti insieme uno script di shell per eseguire la scansione di ogni pagina nel file sitemap generato.
Utilizzare una voce crontab separata e uno script PHP breve per avviare Magento ed eseguire direttamente il processo del crawler.

Qualsiasi pensiero e / o esperienza su questo è il benvenuto!

— davidalger
fonte

In realtà è possibile chiamare il crawler Enterprise da un file separato e utilizzare il crontab dei server per attivarlo in modo che non sia di ostacolo.

— Toon Van Dooren,

È possibile utilizzare l' assedio in combinazione con il sitemap.xmlfile, come fa MageSpeedTest .

#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 corri

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

^{Contenuto proveniente da qui .}

— Ashley Schroder
fonte

Puoi anche aggiungere un ritardo tra le richieste utilizzando–delay

— Ben Lessani - Sonassi

Nota: questi comandi sed non funzionano su Darwin, ma su CentOS.

— davidalger,

Questo non garantisce che ogni URL verrà "riscaldato". assedio selezionerà casualmente gli URL da colpire dal file, ma non visiterà necessariamente tutti gli URL.

— Joe Constant,

Semplicemente non lo facciamo affatto. Mai. Lo diremo ancora e ancora ma

Caching! = Prestazioni

Il tuo sito deve essere veloce senza l'aggiunta di FPC (o Vernice per questo). Ci sarà sempre un momento in cui il contenuto non è pronto (il tuo scenario sopra).

In un negozio senza carico, i tempi di caricamento della pagina con FPC non dovrebbero essere molto più impressionanti di quelli non FPC; Magento è abbastanza felicemente in grado di < 400mscaricare la pagina in cache standard (nelle pagine categoria / prodotto / ricerca). FPC lo porterà a < 80ms- ma viene fornito con avvertimenti.

Le informazioni su stock / prezzo non sono aggiornate fino alla scadenza o alla scadenza TTL
Nuovi articoli / ricerca più pertinente non sono aggiornati fino all'invalidazione o alla scadenza TTL

eccetera.

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

Se stai cercando di assicurarti continuamente che le cache siano caricate manualmente, probabilmente ci sono alcuni motivi

Non hai abbastanza footfall naturale per mantenere le cache innescate (vedi 'Dove FPC è utile')
Il tuo sito è troppo lento senza di loro

Non puoi memorizzare tutto nella cache

Se prendi un negozio con solo 5 categorie, 2 livelli annidati in profondità, 5 attributi filtrabili, 5 opzioni di attributo ciascuno e 1000 prodotti; sono molte le combinazioni possibili.

25 opzioni tra cui scegliere, scegliendone una fino a 5 volte di seguito - Non sono uno statistico , ma sono consapevole che è ... (supponendo che il numero di opzioni di attributo non diminuisca 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 clic: il numero di prodotti disponibili sarebbe diminuito sufficientemente per consentire al cliente di trovare il proprio prodotto. Quindi anche se fosse ...

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

Quindi moltiplicalo per 5 categorie, ovvero 625 URL. In questa fase, stiamo parlando di un piccolo catalogo e ignoriamo completamente tutti gli URL del prodotto.

Inoltre non stiamo prendendo in considerazione il fatto che se avessi categorie nidificate con is_anchoron, aumenterà esponenzialmente.

Quindi, per scansionare quel volume di pagine - o devi sperare che i tempi di caricamento della tua pagina siano carini e bassi, in modo che sia un processo leggero e veloce (sconfiggendo così lo scopo della scansione) - o che tu abbia abbastanza tempo per il completamento prima della scadenza del TTL.

Se le tue pagine avevano un tempo di caricamento della pagina di 0.4s e avevi una CPU a 8 core - allora ...

625 * 0.4 = 250 / 8 = 31 seconds

0,5 minuti, non male, ma immaginiamo che tu abbia avuto tempi di caricamento della pagina 2s

625 * 2 = 1250 / 8 = 156 seconds

Ma se hai preso il massimo scenario possibile

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

Questo è il tuo server di produzione, con un carico della CPU inferiore al 100% per 15 minuti. Riduresti la velocità di scansione in proporzione al TTL che desideri.

Quindi, se si desidera che il contenuto abbia un TTL 3600, la ricerca per indicizzazione potrebbe essere 4 volte più lenta, ad es. solo il 25% di CPU dedicata alla ricerca per indicizzazione. Questa è molta risorsa solo per mantenere il contenuto della categoria innescato - non abbiamo nemmeno preso in considerazione prodotti, termini di ricerca o visualizzazioni aggiuntive del negozio in questa fase

In effetti, solo osservando la mera dimensione delle combinazioni nella catalog_url_rewritestabella (che non include nemmeno il factoring nei parametri della navigazione a più livelli), avrai un'idea di quanti URL potresti finire per dover eseguire la scansione.

Ogni negozio sarà sicuramente diverso, ma quello che sto cercando di colpire a casa è che la scansione del sito per innescare FPC non è pratica. Assicurati solo che il tuo negozio sia veloce per cominciare .

Dove FPC è utile

Dove i vantaggi dell'FPC entrano in gioco è in un negozio pesantemente carico - dove hai livelli di traffico davvero elevati e le cache sono innescate in modo naturale e continuo dalla sola caduta del piede.

FPC entra quindi in gioco riducendo le spese generali dell'infrastruttura sui contenuti comunemente richiesti - riducendo quelle ripetute chiamate al backend Magento.

Quindi abbiamo scoperto che FPC è ottimo da distribuire quando si hanno livelli di traffico molto elevati, non per ridurre il tempo di caricamento della pagina, ma per ridurre l'utilizzo delle risorse.

Chi se ne frega, voglio ancora gattonare

Bene, allora hai due opzioni

Scansione da un modello (ad es. Sitemap)
Estrai i collegamenti pagina per pagina ed esegui la scansione di ciascuno

E ci sono molte utility per fare entrambe queste cose, queste sono alcune che conosco

MAGE-perftest
HTTrack
Nutch
Sphider
Crawler4j

Usando Mage-Perftest

Puoi eseguire la scansione del tuo negozio con Mage-Perftest abbastanza facilmente, prima scaricalo

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*

Quindi definisci il processo di ricerca per indicizzazione utilizzando la Sitemap Magento (puoi personalizzarla creando una Sitemap di qualsiasi URL, a condizione che gli URL siano racchiusi in <loc></loc>tag). Il comando seguente leggerà tutti gli URL dal file Sitemap, quindi eseguirà la scansione (solo PHP) degli URL nel corso di 1440 minuti (1 giorno). Se il server supera il 20% di CPU o una media di carico pari a 2, la ricerca per indicizzazione si interromperà temporaneamente.

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

Se hai 1000 URL, sottoposti a scansione per 1 giorno, saranno circa. 1 richiesta ogni 86 secondi (s) ~ target di 0,011 RPS

— Ben Lessani - Sonassi
fonte

Stai aprendo la linea è molto vero ... la memorizzazione nella cache della pagina non è il modo per ottenere prestazioni. Lo so. Non sai quante volte ho detto ai clienti la stessa cosa. Sarò onesto, non ho mai installato un sito in cui abbiamo un crawler che innesca l'FPC prima e l'ho visto usato solo una volta in cui un client lo ha abilitato nell'amministratore ... rallentando le cose poiché hanno tag di cache basati su file. Il motivo principale che sto chiedendo è perché sto esplorando idee relative a questo sulla base di alcune ricerche nel white paper di Nexcess. Per i siti a traffico follemente elevato, innescare la cache dopo averla

— svuotata

Rispetto Nexcess - ma il loro white paper si concentra molto sulla memorizzazione nella cache per ottenere prestazioni - piuttosto che garantire che l'ambiente sia già performante e che il codice sia pulito, veloce ed efficiente. Forniamo vernice per i nostri clienti, ma non ne sosteniamo l'uso fino a quando non sia necessario. Solo allora come mezzo per ridurre i costi di infrastruttura - vale a dire. quando ~ 94% del traffico non convertito / checkout consuma cicli della CPU. La memorizzazione nella cache fornisce statistiche di benchmark artificiali gradevoli, ma in realtà non significa nulla se i TTL sono troppo lunghi (contenuto non aggiornato) - o non c'è abbastanza traffico per tenerlo innescato.

— Ben Lessani - Sonassi,

Per i siti a traffico follemente alto - ne abbiamo alcuni e cercare di mantenere una cache calda attraverso la scansione artificiale è inutile - il traffico naturale fa proprio questo. Se non altro, la ricerca per indicizzazione rimuove solo le risorse che altrimenti verrebbero utilizzate dai clienti.

— Ben Lessani - Sonassi,

Mi permetto di dissentire dal loro white paper incentrato sull'uso della cache per le prestazioni. Stavano mostrando quanto throughput poteva ottenere un cluster 2 + 1. Non hanno nemmeno toccato i tempi di caricamento della pagina, ma solo il throughput delle transazioni. L'hardware che hanno è quasi ottimizzato quanto si può ottenere ... e sì, mi rendo conto degli effetti dei TTL sul contenuto memorizzato nella cache. Solo per ripetere, non sto cercando di ottenere prestazioni qui, ce l'abbiamo già. Ciò che questo esplorerebbe sarebbe il modo di aggirare i ritardi / le cadute nella velocità di trasmissione a causa dello svuotamento della cache mattutina, vale a dire prima che il traffico normale riprenda.

— davidalger,

Sono confuso allora. Se il tuo negozio è già veloce, ma cade quando si svuota la cache. O a) Non svuotare la cache al mattino, fallo la sera prima e lascia che la ricerca esegua la scansione dei robot (google / bing ecc.) Eseguendo il priming per te oppure b) ottenga la giusta infrastruttura. Se il tuo negozio si basa su FPC / Vernice per prevenire ritardi / rallentamenti - allora sembra che stai correndo sul bordo di un coltello ...

— Ben Lessani - Sonassi,

Di questi tempi risparmierò il mio rant per un post sul blog, ma nel frattempo ho un picco nel mio piccolo scalda cache wfpc.

Test delle prestazioni

Puoi testare le prestazioni del tuo 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

Riscaldamento FPC

E puoi riscaldare l'FPC, che colpirà ogni URL in sitemap.xml.

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

Puoi anche mettere un ritardo tra le richieste, se lo desideri, ecco un ritardo di 1 secondo tra le richieste.

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

La modalità test colpisce solo 10 URL in modo casuale, quindi una volta riscaldato l'FPC, puoi eseguire la modalità test per scoprire quanta differenza fa l'FPC!

Pensieri

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

— quickshiftin
fonte