Faccio fatica a trovare buoni esempi funzionanti di quali modifiche sono necessarie per consentire a Varnish di memorizzare nella cache un sito Magento.

Idealmente, vorrei un elenco di attività, come cose da disabilitare / abilitare e dove cercarle. Sarebbe anche bello avere la configurazione di vernice con cui quei cambiamenti sono progettati per funzionare.

La guida alle prestazioni di Magento parla molto di Varnish, quindi so che è stato fatto prima, tuttavia in realtà non spiega come farlo funzionare.

Hanno un modulo ufficiale proprio qui . Include tutto ciò di cui hai bisogno (config vernice, modulo, ...)

Varnish è giusto per te?

La vernice non è l'essenziale per tutte le prestazioni di Magento. È fantastico compensare il carico di bot e acquirenti di finestre, ma non dovrebbe essere il tuo primo punto di riferimento per rendere il tuo negozio più veloce.

In effetti, l'implementazione di Varnish dovrebbe essere l' ultima modifica delle prestazioni al tuo negozio. Inseriscilo solo quando vedi i tempi di caricamento della pagina che Magento è in grado di offrire senza di essa (ad es. <Tempi di caricamento della pagina <600ms).

Il tuo negozio deve ancora essere veloce

Poiché Varnish richiede ancora almeno un singolo caricamento della pagina per adescare la cache, significa che le prestazioni non memorizzate nella cache devono essere ancora molto buone. Una vasta maggioranza di URL unici (hit di navigazione a più livelli, query di ricerca ecc.) Non finiranno mai per essere offerti da Varnish a meno che:

a) I tuoi TTL sono così alti che una query di ricerca di 4 giorni fa è ancora valida oggi
b) Il footpath sul sito è così vasto che gli URL vengono popolati in un tempo molto breve

Devi anche considerare che non tutti i negozi si prestano a Vernice . Qualsiasi sito che incoraggi gli utenti a creare una sessione personale (ad es. Accesso, aggiunta al carrello, ecc.) Nelle prime fasi del percorso del cliente comporterà la ridondanza di Varnish.

Ad esempio, i siti di shopping privati ​​incoraggiano l'accesso degli utenti dal set, tuttavia, nel fare ciò, Varnish non ha mai contenuti non unici che sono in grado di memorizzare nella cache. Quindi i tuoi hit rate saranno drasticamente bassi e non ci sarà alcun beneficio dall'uso di Varnish.

Nuovi contenuti o percentuali di hit più elevate

^{Immagine gentilmente concessa da magestack.com}

Utilizzare Varnish in modo efficace significa trovare un equilibrio tra il contenuto non aggiornato e la quantità di visitatori sul tuo sito.

Se hai un sito affollato - le probabilità sono che puoi cavartela con TTL più bassi e avere comunque un alto tasso di successo di Vernice - e continuare anche ad avere TTL bassi - quindi, contenuti più freschi. In questo modo le variazioni di azioni / prezzi si riflettono rapidamente e la cache viene continuamente innescata dal volume di calpestio.

Se hai un sito a basso traffico, dovrai scendere a compromessi. Aumenta i tuoi TTL per garantire un tasso di successo più elevato o disponi di contenuti aggiornati. Non puoi avere entrambi. Sì, è possibile eseguire continuamente uno strumento di ricerca per indicizzazione / spider, ma le risorse che questo consumerebbero e il semplice volume o URL che possono essere sottoposti a scansione (di solito in decine di migliaia per piccoli negozi) significa che è semplicemente non efficace. Di solito, i negozi più piccoli trarrebbero maggiori benefici da una buona estensione FPC e da una configurazione del server altamente ottimizzata.

Ma ovviamente posso usare Varnish anche quando gli utenti hanno effettuato l'accesso, che dire della cache per utente o delle ESI?

ESI

Le ESI sono un'eccellente utility per essere in grado di conservare il contenuto nella cache e di avere ancora blocchi dinamici sulla pagina. Ma per essere utilizzato in modo efficace, è necessario ridurre al minimo la quantità di richiamate. C'è un piccolo modulo di avvio che puoi usare come base per questo processo - assicurati solo di stringere i buchi di sicurezza in esso, è molto insicuro per impostazione predefinita - non ci sono restrizioni su quali handle di layout puoi / non puoi caricare

Ogni volta che viene caricato il bootstrap Magento, si arriva a una penalità di prestazione di circa 200 ms - prima ancora di caricare una raccolta / renderizzare un blocco ecc. Quindi se hai più di 3 ESI, le probabilità sono che tu sia finito tempi di caricamento della pagina più lenti utilizzando Varnish + ESI per contenuti dinamici, piuttosto che bypassare Varnish e passare la richiesta direttamente a Magento stesso.

Quindi, per utilizzare davvero le ESI in modo efficace, devi essere in grado di combinare più richieste in un'unica richiesta.

Ad esempio, una pagina di visualizzazione della categoria che elenca 20 prodotti deve mostrare livelli di scorte accurati. Quindi usi ESI per ogni blocco della pagina. Sarebbero 20 richieste di titoli ESI. Mentre le richieste di stock sono molto leggere, eseguirne 20x simultaneamente comprometterebbe le prestazioni. Quindi, invece, potresti servire l'intero blocco / raccolta di 20 prodotti e ottenere quella richiesta 1x. Ma il caricamento e il rendering della raccolta è probabilmente l'elemento più lento della pagina, quindi non hai guadagnato molto.

L'utilizzo di ESI richiede effettivamente una corretta progettazione ed esecuzione, altrimenti avrai un sito più lento rispetto al non usare affatto Varnish.

Cache-per-user

Quindi esiste l'alternativa all'utilizzo di una cache specifica dell'utente. Questa è una cattiva idea a meno che tu non abbia un sito a basso traffico. Il tuo tasso di hit sarà terribilmente basso - poiché le probabilità che un visitatore colpisca la stessa pagina in cui è già stato sono molto basse. E per ogni cliente, quella pagina da 6Kb occuperà sempre più spazio nel cestino di archiviazione di Varnish.

Ad esempio, se hai assegnato 1 GB a Varnish. Con un sito tipico in cui gli utenti visualizzano 8 pagine per visita, in media 6 di tali pagine saranno uniche. Quindi sono 28 visitatori per 1 MB di spazio di archiviazione. Quindi includi le tue immagini, CSS e JS: questi (per fortuna) saranno comuni, ma probabilmente occuperanno comunque ben 7-800 MB di spazio di archiviazione disponibile. Questo ti lascia con 200 MB di spazio di archiviazione rimanente, abbastanza cache per 5.600 visitatori unici.

Beh, non mi interessa, voglio solo vernice

Bene, allora dovrai fare quanto segue:

1. Installa un terminatore SSL per sederti prima di Varnish (es. Stud / pound / nginx)
2. Installa Varnish sul server
3. Assicurati di configurare X-Forwarded-Forcorrettamente
4. Installa un modulo di vernice sul tuo negozio
5. Imposta i tuoi VCL Varnish per escludere estensioni di terze parti

Poiché i primi 3 punti vanno oltre lo scopo di questa risposta, lo lascerò a te stesso da gestire. Il punto 4 è un gioco da ragazzi e con il punto 5 - continua a leggere.

La cosa più importante sull'implementazione di Varnish è assicurarsi di non memorizzare mai nella cache contenuti che non dovrebbero mai essere memorizzati nella cache.

Per esempio.

• Richiamate del gateway di pagamento
• Panoramica del carrello
• Panoramica del mio account cliente
• Acquista (e rispettive chiamate Ajax)

eccetera.

Per gli URL Magento di base, esiste un elenco abbastanza standard di URI che puoi sfuggire a Varnish:

admin|checkout|customer|catalog/product_compare|wishlist|paypal

Ma devi anche considerare eventuali estensioni personalizzate / di terze parti che stai eseguendo che hanno percorsi, router e spazi dei nomi personalizzati. Sfortunatamente, non esiste un modo semplice per sapere quali URL di queste estensioni possono e non possono essere memorizzati nella cache. Quindi è necessario valutare ciascuno caso per caso.

Di norma, ogni volta che configuriamo Varnish, inizieremo identificando i rispettivi percorsi, router e spazi dei nomi che potrebbero occupare e passare da lì. Lo facciamo tramite SSH:

grep -Eiroh "<frontName>.*</frontName>" community | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" community | grep "<from>"
grep -A5 -ir "<routers>" community 
grep -Eiroh "<frontName>.*</frontName>" local | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" local | grep "<from>"
grep -A5 -ir "<routers>" local 

Questo non ti darà un elenco definitivo di URL, ma ti darà quasi sicuramente un punto di partenza.

Non possiamo sottolineare quanto sia importante non memorizzare mai nella cache contenuti che non dovrebbero essere memorizzati nella cache. I risultati potrebbero essere catastrofici.

In sintesi

Come con qualsiasi altra ottimizzazione delle prestazioni del server Magento, l'implementazione e l'ottimizzazione corretta possono davvero portare vantaggi. Ma semplicemente entrare nel software senza configurarlo correttamente non solo renderà il tuo negozio non più veloce, ma potenzialmente più lento, più insicuro e meno affidabile.