Cache pagina completa su CE 1.8 - Un modulo Magento FPC? Vernice? Tutti e due?

Quindi sono un po 'confuso mentre vado alla ricerca di Full Page Caching per Community Edition 1.8. Ho già implementato una Redis Cache a due livelli, CDN, sintonizzato su my.cnf di MySQL per le massime prestazioni (ovviamente il DB si trova su un server separato) e ho 2 server che ospitano il nostro negozio dietro un bilanciamento del carico. Dico questo per sottolineare che non sto saltando immediatamente per l'FPC prima di fare le modifiche iniziali alle prestazioni.

Non ho mai usato Varnish prima su qualsiasi tipo di sito, figuriamoci Magento, e non ho mai nemmeno creato un FPC in Magento. Comprendo che Varnish è un proxy che agisce da solo tra un CDN e una cache di pagina, inviando i dati al browser prima che la richiesta arrivi anche al web server. E per quanto ne so, un modulo FPC crea una cache locale che il server web stesso fornisce. So che per entrambe le configurazioni, è necessario eseguire alcuni "Punzonatura" per ottenere il contenuto dinamico attraverso il browser (anche se le tecniche sono diverse, tra l'utilizzo di un modulo o l'utilizzo di Varnish). Per favore, correggimi se fraintendo qualcosa qui.

Fino ad ora, ho pensato a loro come a due entità separate che potevi implementare per aiutare il tuo sito, ma ora qualcosa che ho letto sembra implicare il contrario. Il mio piano originale era quello di acquistare il modulo " Warp Advanced Full Page Cache " per Magento (precedentemente "FPC Tiny Brick Lightspeed", credo) in quanto sembra essere il più popolare, anche se un tocco sul lato più costoso (ma, francamente , $ 350 non sono molto per la nostra azienda, soprattutto per quello che può fare). Io e due dei miei colleghi sviluppatori stavamo pianificando di imparare a implementarlo correttamente e pienamente nel nostro tema personalizzato e fatto in casa per massimizzare ciò che possiamo ottenere da esso. Dopodiché, ad un certo punto lungo la strada, ho pensato che avrei cercato di implementare anche Varnish, ma, come ho detto prima, avevo capito che erano separati.

Ora, tuttavia, sto iniziando a trovare estensioni come questa PageCache Powered by Varnish che è gratuita, o questa Vortex Cache Powered by Varnish Cache che costa quasi $ 800 USD, che sono moduli Magento Full Page Cache che funzionano direttamente con Varnish.

La mia domanda per te, scambio di stack, è come dovrei vedere un FPC e una vernice? Come entità separate? In tal caso, si escludono a vicenda? Sono due facce della stessa medaglia che dovrei implementare insieme? O sono simili ma né esclusivi né inclusivi l'uno dell'altro?

Posso usare l'FPC Warp Advanced che ho menzionato sopra con Varnish? Dovrei usarlo con Varnish? O sarebbe meglio usare un FPC diverso se ho intenzione di usare Varnish? O ancora di più, c'è un FPC così buono che non ho bisogno di vernice? O viceversa, dovrei semplicemente usare Varnish e abbandonare l'idea FPC?

Ci scusiamo per il muro di testo, ma ho esaminato molti articoli, blog e post di forum e non sono stato in grado di discernere una risposta definitiva a tali domande. Apprezzo molto il tuo aiuto e input in questa materia =)

Oh, e infine, una rapida domanda su Varnish e i server web. Attualmente sto usando la normale configurazione dello stack LAMP di Apache, ma da un po 'di tempo vedo persone entusiaste nell'uso di Nginx con Magento. Ho fatto alcuni test da solo, stress e test di carico, e sembra che possa sicuramente funzionare un po 'meglio nelle giuste condizioni. In quanto tale, stavo pensando di passare ad un certo punto nel prossimo futuro. Ciò influenzerebbe comunque il mio desiderio e la mia decisione di usare un FPC e / o una vernice?

Grazie!!!

EDIT: Oh! E un'altra domanda veloce: poiché ho due server che ospitano il mio sito dietro un bilanciamento del carico (che è anche una configurazione che può essere aumentata in orizzontale in caso di necessità), utilizzo pienamente Redis e Memcached ospitati su un server separato dal Web e DB per le mie sessioni e ogni livello della cache a due livelli di Magento (beh, di Zend). Presumo che l'FPC memorizzerebbe i suoi dati in uno di questi su sistemi? Dovrei avere un'estensione specifica per archiviarlo lì o lo fanno tutti? E mentre presumo di no, ciò influenzerebbe comunque la vernice? Grazie ancora!!

Ci sono due cose difficili nell'informatica:

1. Nominare le cose
2. Annullamento della cache.

La perforazione rientra nella categoria # 2 :)

Generale

L'approccio migliore è iniziare nei punti più bassi dello stack e ottimizzare fino al frontend di Magento.

Database e filesystem

Dovrebbero essere sempre le prime aree su cui concentrarsi. Perché. I / O.

MyTop è un utile script perl basato su Linux che imiterà il comando "top" di Linux e ti fornirà informazioni sullo stato delle tue istanze di MySQL.

• https://github.com/jzawodn/mytop

Htop è un top più robusto , La funzione Strace può aiutare a determinare i dettagli di un processo per trovare potenziali colli di bottiglia.

• https://github.com/hishamhm/htop

Iotop è un altro strumento da considerare per il monitoraggio degli I / O.

• http://guichaz.free.fr/iotop/

Altri utili script di utilità come mysqltuner.pl e mysql tunning primer possono offrire informazioni dettagliate sulle variabili di runtime di MySQL e offrire consigli per aiutarti. Tieni presente che queste sono pensate come guide poiché l'approccio migliore è sempre una valutazione dei requisiti e un'ottimizzazione basata su dati noti raccolti. Farlo ciecamente può causare a volte più danni che benefici. E eseguirli prematuramente senza almeno 24 ore di variabili di runtime mysql può offrire cattivi consigli.

• http://mysqltuner.pl
• https://launchpad.net/mysql-tuning-primer

Tieni presente che Percona , MariaDB e MySQL standard dovrebbero funzionare con tutto quanto sopra. Favorire Percona come un fork di MySQL, poiché Magento è così pesante su InnoDB e XtraDB offre molti strumenti e miglioramenti al motore db.

• http://www.percona.com/software
• https://mariadb.org/en/about/

Apache o Nginx

Uso ancora Apache perché ha funzionato bene in molti altri, me compreso. Ho usato e configurato anche Nginx. Mentre offre alcuni vantaggi c'è una curva di apprendimento. Mentre le due sono entrambe opzioni popolari, offre alcuni vantaggi rispetto ad Apache, una sarebbe un footprint di memoria più piccolo. Tuttavia, un Apache minimizzato che esegue PHP-FPM avrà un footprint di memoria simile.

• http://arstechnica.com/business/2011/11/a-faster-web-server-ripping-out-apache-for-nginx

Caso in questione:

Dal momento che questo articolo riguardava le prestazioni, dovrei sottolineare che uno dei modi più semplici per aiutare Apache a fare a modo suo è di non utilizzare i file .htaccess. Inserisci ciò che avresti inserito nelle stanze della directory, imposta AllowOverride su "Nessuno" e finisci per non chiedere ad Apache di percorrere l'intero percorso del documento per capire se deve prestare attenzione a .htaccess o meno. Questo è un semplice suggerimento di sintonia che molte persone sembrano perdere.

Per facilitare questo check out:

• https://github.com/preinheimer/htaccessConverter

L'uso di una CDN per aiutare a rilassare l'una o l'altra aiuterà ovviamente ma avrà un ulteriore vantaggio sull'ottimizzazione del frontend poiché la maggior parte dei browser degli utenti finali sarà in grado di connettersi a entrambi i server con lo stesso numero di limiti di connessione. Ciò inoltre libera Apache dal non dover saltare i controlli e solo per offrire una semplice immagine statica. Lighthttpd è un'opzione se si desidera eseguire un server Web statico solo per contenuti oltre a una CDN.

PHP

PHP-FPM e APC. Usali, rimuovi tutti i moduli PHP non necessari o non necessari per Magento.

Base di codice Magento

AOE_TemplateHints è ottimo per determinare se i blocchi vengono memorizzati correttamente nella cache:

• https://github.com/fbrnc/Aoe_TemplateHints
• http://www.fabrizio-branca.de/magento-advanced-template-hints-20.html

AOE_Profiler è buono per la profilazione, assicurati di abilitare la profilazione del suo livello DB (ovviamente in un ambiente locale / dev). Questo, in combinazione con lo strumento mytop menzionato in precedenza, rende più facile la ricerca di comportamenti scorretti SQL.

• https://github.com/fbrnc/Aoe_Profiler

Moduli di terze parti e codice personalizzato

Alcune buone pratiche per l'ottimizzazione di Magento sono una buona lettura e da tenere a mente quando si esaminano i moduli di terze parti prima di usarli. (ce ne sono molti di quelli che si comportano male IMO).

• http://info.magento.com/rs/magentocommerce/images/Conquer_the_5_Most_Common_Magento_Coding_Issues_to_Optimize_Your_Site_for_Performance.pdf

Uno strumento Magniffer di Magento ECG aiuterà a identificare facilmente il codice di comportamento scorretto in base al PDF fornito sopra. È basato su symfony / php-parser ma può essere installato tramite compositore.

• https://github.com/magento-ecg/magniffer

Vernice

Come avvocato di Varnish, l'autore era un dev del kernel di FreeBSD, offre alcuni pazzi tempi di caricamento second second. Tuttavia, se hai anche alcune delle minime differenze nei tuoi modelli che non sono fuori dalla scatola, passerai il tempo a configurare vernice / magento per olepunch il contenuto di cui hai bisogno. La maggior parte che ho visto semplicemente AJAX 'identificherà gli oggetti necessari staccati da Vernice.

Esistono numerosi moduli Magento per facilitare questa perforazione e memorizzazione nella cache:

• AOE_Static: https://github.com/AOEmedia/Aoe_Static
• Nexcess Trementina: https://github.com/nexcess/magento-turpentine

In definitiva, questo dovrebbe essere all'ultimo estremo del tuo viaggio di ottimizzazione e PUO ' richiedere un po' di personalizzazione per ottenere le cose giuste.

Magento CE FPC

Finora il miglior FPC CE che ho trovato è: Lesti :: FPC

è un FPC open source e gratuito molto ben messo insieme (basato su tutti gli osservatori) per la comunità.

• http://gordonlesti.com/lestifpc/
• https://github.com/GordonLesti/Lesti_Fpc (github in caso di collegamento futuro morto)

Alla fine della giornata usa i tuoi test e il tuo giudizio.

Qualche ulteriore lettura:

• http://www.kingletas.com/2012/08/caching-performance-optimization.html
• https://www.sonassi.com/knowledge-base/magento-with-varnish/
• http://info.magento.com/rs/magentocommerce/images/HostandBoastBestPracticesForMagentoHosting.pdf

So un po 'tardi a questa discussione, ma se stai ancora cercando una soluzione, potresti prendere in considerazione, Evolved Caching . È lo stesso prezzo di Warp, ma:

• È molto semplice e veloce da installare e configurare: tutti i fori e la configurazione sono eseguiti dall'amministratore
• Si integra direttamente con Varnish e ti consente di svuotare e riscaldare la cache di Varnish da Magento
• Funziona con il front-end form_key introdotto in 1.8 CE sia in Varnish che nella sua cache.
• È molto attivamente sviluppato con supporto reattivo. Nuove versioni regolari con l'obiettivo di rilasciare correzioni di bug entro pochi giorni dalla segnalazione
• Ha una vasta documentazione che viene aggiornata ad ogni versione

L'impostazione con Varnish è semplice, devi solo abilitare un'impostazione amministratore e utilizzare il .vcl che trovi qui . Inoltre, non sei limitato a Varnish che serve solo cache quando non sono presenti cookie come al solito - ottieni una percentuale di hit della cache molto alta.

Abbiamo scritto un FPC compatibile con la nuova chiave del modulo Magento 1.8. Cache a piena pagina di Brim: http://ecommerce.brimllc.com/full-page-cache-magento.html

BOOMER è un ottimo punto per iniziare in basso nello stack e farti salire. Un FPC o vernice dovrebbe essere l'ultimo che fai. Effettuiamo controlli delle prestazioni e troviamo comunemente problemi con le configurazioni MySQL e APC che sono davvero fuori. Come le dimensioni del buffer Innodb impostate sul valore predefinito e il database è cresciuto molto oltre.

Si sconsiglia di utilizzare qualsiasi FPC con vernice, se non specificamente progettato per lavorare insieme. In generale, non raccomandiamo Varnish a meno che tu non abbia una manciata di server robusti che sono stati tutti sintonizzati con la tua base di codice e stanno ancora lottando per mantenere il traffico. L'aggiornamento dei contenuti dinamici può essere complicato con Varnish in particolare quando si tenta di limitare le richieste al back-end di Magento e, a sua volta, ridurre il carico. Se hai uno o due web head, i guadagni potrebbero non valere il tempo e le complicazioni.

Nella maggior parte dei casi un buon FPC ti offre le prestazioni di cui hai bisogno, ovviamente dopo che il tuo server e la tua base di codice sono stati messi a punto. Con il nostro FPC puoi ottenere tempi di generazione inferiori a 15 ms nella cache di livello 1 e inferiori a 100 ms nella cache standard. La nostra cache di livello 1 viene utilizzata nei casi in cui l'utente non ha effettuato l'accesso e non ha nulla nel carrello in quanto non esegue la perforazione. Quando una di queste condizioni è falsa, viene utilizzata la cache standard con supporto per la perforazione completa.

Il nostro FPC è dotato di una semplice perforazione integrata e funziona immediatamente con tutti i blocchi Magento standard e con qualsiasi blocco personalizzato che potresti avere. È tutto configurabile tramite il pannello di amministrazione.

Ti consiglierei di attenermi a Redis a meno che tu non abbia problemi di ridimensionamento con esso. Ha il supporto per tag ed è molto più veloce di memcached con file o database come backend lento. Se desideri tag e pulizia coerenti, devi utilizzare memcached con il database quando disponi di più web head. Con il supporto per tag di Redis integrato, non devi preoccuparti. Puoi anche usare Redis per le tue sessioni.

Posso parlare per tutti gli FPC, ma con i nostri è possibile configurare tramite l'amministratore dove memorizzarlo. Puoi scegliere di utilizzare il back-end di cache Magento predefinito o specificare impostazioni personalizzate per utilizzare File, Database, APC, Redis, Memcache e un back-end di file ottimizzato.

Non c'è una risposta corretta. Un negozio dovrebbe avere caricamenti di pagine dinamiche sub 3 e idealmente 1-2 caricamenti di pagine dinamiche, il secondo non è necessario ed è principalmente una statistica guidata dal marketing. Apache è facile da imparare e difficile da eseguire, Nginx è difficile da imparare e facile da eseguire, molti siti si stanno spostando su Nginx ma avere un'architettura di alta qualità basata su Nginx e Magento non è semplice.

I cluster Magento multi-server sono già complessi da implementare e ancora più difficili da mantenere se non sull'architettura corretta, normalmente lavoriamo con cluster più grandi che rendono tutto più fluido, incluso il posizionamento. Lo facciamo con la configurazione di installazione standard con modifiche minori per la stabilità a medio e lungo termine indirizzata ai carichi dinamici della pagina 1-2, rendendo tutto molto più semplice per la manutenzione.

La vernice può essere un FPC, CDN tra gli altri, tuttavia nel tuo caso è meglio pensarlo come un FPC. Un FPC consente a più visitatori sul server e fornisce una consegna statica più rapida di cui Varnish è uno di questi strumenti, tuttavia ci sono vari problemi con esso tra cui contenuto dinamico, controllo delle scorte, prezzi. La risposta sta nel modo in cui è strutturata la tua attività, in che modo vengono caricati i tuoi dati, con quale frequenza, il tipo di hosting e altro, la tua attività viene semplicemente influenzata fornendo contenuti statici ai visitatori. È possibile mitigare tecnicamente gran parte di ciò con la configurazione FPC, tuttavia ciò complica l'ambiente aziendale, dal punto di vista del proprietario di un'azienda potrebbe non produrre un ritorno sugli investimenti equilibrato.

L'FPC è l'ultima parte se hai sub 3 o un caricamento dinamico migliore, la tua architettura è in grado di gestire le richieste dei visitatori in quanto influisce sul posizionamento, assorbe picchi di marketing e festivi e ha il budget per aggiungere complessità all'architettura del server - l'hosting dovrebbe essere 0,5 -1% delle entrate per le piccole imprese, la maggior parte delle quali è sostanzialmente soggetta a questo problema, causando numerosi problemi commerciali indiretti.

Il motivo per cui non hai trovato una risposta definitiva è dovuto al fatto che quelle domande richiedono mesi per rispondere in quanto sono qualitative (basate sul business) che richiedono informazioni che un'azienda non vorrebbe pubblicare pubblicamente, le velocità di caricamento della pagina sono quantitative (basate su tecniche ) che può essere pubblicato pubblicamente, è come combinare i due elementi che rendono la soluzione.

Puoi usare questa cache della pagina Magento che si adatta alle tue esigenze ed è simile alla vernice. È utilizzato da molti dei più grandi negozi Magento. Alcune caratteristiche:

1. Come Varnish, non utilizza una connessione al database per il 90% delle richieste. Di conseguenza, è estremamente veloce
2. Ha la capacità di scaricare automaticamente le pagine quando cose come l'inventario dei prodotti cambiano ed è molto bravo in questo
3. È una cache a più livelli, quindi supporta anche la perforazione quando gli utenti effettuano l'accesso (queste richieste richiedono l'uso del database)

Essendo una cache multilivello è scalabile anche per i negozi con il traffico più elevato ed è stato utilizzato su molti siti a traffico estremamente elevato che ricevono traffico di picco come i negozi presenti su SharkTank (programma televisivo)