Completa Cache Pagina su CE 1.8 - Un modulo FPC Magento? Vernice? Tutti e due?

magento.stackexchange https://magento.stackexchange.com/questions/13957

Domanda

Quindi, io sono un po 'confuso, come vado circa la ricerca completa Pagina Caching per Community Edition 1.8. Ho già implementato un Due livello Redis Cache, CDN, sintonizzati my.cnf di MySQL per le prestazioni max (w / DB essere su un server separato, naturalmente), e ho 2 server che ospitano il nostro negozio dietro un bilanciatore di carico. Io dico che a sottolineare che non sto saltando subito per la FPC prima di fare i ritocchi prestazioni iniziali.

Non ho mai usato vernice prima su qualsiasi tipo di sito, per non parlare di Magento, e non ho mai creato un FPC in Magento sia. Capisco Varnish per essere un proxy che agisce come un incrocio tra un CDN e una cache pagina su di essa la propria, l'invio dei dati al browser prima che la richiesta diventa ancora al server web. E per la mia comprensione, un modulo FPC crea una cache a livello locale che il server web in sé piatti fuori. So che per entrambe le configurazioni, è necessario fare un po ' "Hole Punching" per ottenere il contenuto dinamico attraverso il browser (anche se le tecniche sono diverse, tra l'utilizzo di un modulo o utilizzando vernice). Si prega di correggere me se vengo malinteso nulla qui.

Fino a poco fa, ho pensato a loro come due entità separate che si potrebbe attuarla aiutare il vostro sito, ma ora somethings ho letto sembrano implicare il contrario. Il mio piano originale era quello di acquistare la " ordito avanzato piena pagina Cache " modulo per Magento (ex 'piccolo mattone Lightspeed FPC', credo) come sembra essere il più popolare, se un tocco sul lato più costoso (ma, francamente, $ 350 non è molto per la nostra azienda, soprattutto per quello che può fare). Io e 2 dei miei colleghi sviluppatori stavano progettando sull'apprendimento per attuare correttamente e pienamente all'interno del nostro costume, tema fatto in casa per massimizzare quello che possiamo uscirne. Dopo di che è stato fatto, ad un certo punto lungo la strada, ho pensato che avrei guardare in attuazione della vernice, come pure -., Ma, come ho detto prima, le avevo capito di essere separati

Ora, però, sto iniziando a venire attraverso le estensioni come questo pagecache Azionato da Varnish che è libero, o questo vortice cache Azionato da Varnish Cache, che è quasi $ 800 USD, che sono i moduli Magento Pagina intera cache che opera direttamente con Vernice .

La mia domanda a voi, lo scambio di stack, è come dovrei vedendo un FPC e vernice? Come entità separate? Se è così, sono essi escludono a vicenda? Sono due facce della stessa medaglia che dovrei implementare insieme? O sono simili, ma non esclusiva né comprensivo di uno con l'altro?

È possibile utilizzare il filo di ordito avanzato FPC ho citato sopra con vernice? dovrebbe Io lo uso con vernice? O sarebbe meglio usare un FPC diverso se ho intenzione di utilizzare per unghie? O ancora di più, c'è un FPC così buono che non ho bisogno di vernice? O viceversa, devo solo usare vernice e il fossato l'idea FPC?

Ci scusiamo per il muro di testo, ma mi è stato guardando un sacco di articoli, blog e post del forum, e non sono stato in grado di discernere una risposta definitiva a queste domande. Ho veramente apprezzato il vostro aiuto e l'ingresso in questa materia =)

Oh, e, infine, una domanda veloce su vernici e server web. Attualmente sto usando configurazione normale Apache stack LAMP, ma da un po 'quando ho visto la gente rave sull'utilizzo di Nginx con Magento. Ho fatto alcuni test me, test di stress e di carico, e sembra che può sicuramente lavorare un po 'meglio nelle giuste condizioni. Come tale, stavo considerando di passare a un certo punto in un prossimo futuro. Sarebbe questo in alcun modo influenzare il mio desiderio e la decisione di utilizzare un FPC e / o vernice?

Grazie !!!

EDIT: Oh! E una domanda più rapido - Dal momento che ho due server che ospitano il mio sito dietro un bilanciatore di carico (che è anche una configurazione che può essere aumentato in orizzontale in caso di necessità), io fare pieno uso delle Redis e Memcached ospitato su un separaserver di te dal Web e quelli DB per le mie sessioni e ogni livello di Magento di (o meglio, di Zend) a due livelli di cache. Suppongo che il FPC sarebbe memorizzarlo di dati in uno di quelli ai sistemi? Avrei bisogno di avere un interno specifico per memorizzare lì o se invece tutti lo fanno? E mentre io non presumo, sarebbe le conseguenze per unghie in ogni caso? Grazie ancora !!

È stato utile?

Soluzione

Ci sono due cose difficili in informatica:

  1. Naming cose
  2. invalidazione della cache.

La perforazione rientra nella categoria # 2:)

Generale

L'approccio migliore è quello di iniziare in corrispondenza dei punti più bassi della pila e ottimizzare fino al frontend di Magento.

database e file system

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

mytop è un pratico script perl basato su Linux che imitare il comando di Linux 'top' e vi darà una visione sullo stato della propria istanza di MySQL (s).

Htop è un più robusto top , Il strace caratteristica può aiutare a determinare ins / out di un processo per trovare potenziali colli di bottiglia.

iotop è un altro strumento da considerare per il monitoraggio di I / O.

Altri script a portata di mano di utilità come mysqltuner.pl e mysql tunning Primer in grado di offrire comprensione le variabili di runtime MySQL e offrire consigli per aiutare. Tenete a mente questi sono destinate ad essere guide come il miglior approccio è sempre una valutazione dei requisiti e messa a punto in base ai dati raccolti noti. Ciecamente così facendo può causare più danni a volte che bene. E prematuramente in esecuzione questi senza almeno 24 ore di variabili mysql runtime può offrire un cattivo consiglio.

Tenga presente Percona , MariaDB e MySQL di serie dovrebbero funzionare con tutto quanto sopra. Favorendo Percona come una forcella MySQL, poiché Magento è così pesante sul InnoDB e XtraDB offre molti strumenti e miglioramenti al motore db.

Apache o Nginx

Sempre utilizzando Apache come ha servito bene molti altri, me compreso. Ho usato e configurato Nginx pure. Mentre esso offre alcuni vantaggi v'è una curva di apprendimento. Mentre i due sono entrambe le opzioni popolari, che offre alcuni vantaggi rispetto Apache, uno sarebbe una minor richiesta di memoria. Tuttavia, un sottile abbattuto Apache in esecuzione PHP-FPM avrà una memoria simile ingombro.

Caso in questione:

Dal momento che questo articolo è stato sulle prestazioni, Tengo a precisare che uno dei modi più semplici per aiuto apache uscire dal suo proprio modo è quello di non usare i file .htaccess. Metti quello che ci si mette lì nella directory strofe, impostare AllowOverride su "None" e si finisce per non chiedere apache per attraversare il percorso intero documento per capire se ha bisogno di pagare attenzione a .htaccess oppure no. Questo è un semplice, semplice suggerimento sintonizzazione che molte persone sembrano perdere.

Per facilitare questo check-out:

Utilizzando un CDN per contribuire a prendere la facilità fuori di entrambi aiuto, ovviamente, ma avrà aggiunto vantaggio sull'ottimizzazione frontend poiché la maggior parte degli utenti finali dei browser sarà in grado di connettersi a entrambi i server con lo stesso numero di limiti di connessione. Questo consente di liberare anche Apache da non dover passare attraverso controlli e quali solo per servire un'immagine statica semplice. LightHTTPD è un'opzione se si desidera eseguire un server statico web solo per i contenuti oltre ad una CDN.

PHP

PHP-FPM e APC. usarli, togliere tutti i moduli PHP non necessari o non necessari non necessari per Magento.

Magento codebase

AOE_TemplateHints è grande per determinare se i blocchi memorizzano nella cache correttamente:

AOE_Profiler è un bene per il profiling, essere sicuri e consentire il suo strato DB profilatura (in un ambiente / dev locale, ovviamente). Questo in collaborazione con il mytop strumento accennato in precedenza fa trovare cattivo comportarsi SQL un compito più facile.

moduli 3rd Party & codice personalizzato

Alcune molto buone le best practice per l'ottimizzazione da Magento se stessi è una buona lettura, e da tenere a mente al momento di rivedere i moduli 3rd party prima di utilizzarli. (Ci sono un sacco di quelli Comportarsi male IMO).

Uno strumento Magniffer da Magento ECG vi aiuterà a identificare facilmente codice di comportarsi male in base alla PDF fornito sopra. E 'symfony / php-parser basato però, ma installabile tramite compositore.

Vernice

uno non è sufficiente accendere vernice

Come un sostenitore di vernice essere l'autore era un FreeBSD kernel dev, offre alcune volte secondo carico pazzo sub. Tuttavia, se si hanno anche alcune delle minime differenze nei modelli che non è fuori della scatola, vi permetterà di trascorrere tempo a configurare vernice / Magento per holepunch i contenuti che vuoi. La maggior parte che ho visto sarà semplicemente AJAX'ify gli elementi necessari non memorizzata nella cache da Varnish.

Ci sono una serie di moduli di Magento per contribuire a facilitare questo perforazione e la cache:

In definitiva questo dovrebbe essere l'ultimo fine del vostro viaggio di ottimizzazione, e MAGGIO richiede qualche personalizzazione per ottenere le cose a posto.

Magento CE FPC

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

è molto ben messo insieme (tutti osservatore based) open-source e gratuito per FPC comunitario.

Alla fine della giornata utilizzare il proprio test e giudizio.

Qualche ulteriore lettura:

Altri suggerimenti

Un po 'in ritardo a questo thread lo so, ma se siete ancora alla ricerca di una soluzione, allora si può prendere in considerazione, Evolved Caching . E 'lo stesso prezzo di curvatura, ma:

  • è molto veloce e facile da installare e configurare - tutto punzonatura buco e configurazione viene fatto all'interno di amministrazione
  • Si integra direttamente con vernice e consente di limpida e calda la cache Varnish dall'interno Magento
  • Funziona con il form_key frontend introdotto in 1,8 CE sia in vernice ed è propria cache.
  • è molto attivamente sviluppato con il supporto reattivo. Regolari nuove versioni con l'obiettivo di rilasciare correzioni di bug nel giro di pochi giorni di segnalazione
  • documentazione che è aggiornato ad ogni rilascio

Impostazione con vernice è semplice, basta attivare un ambiente di amministrazione e utilizzare il .vcl trovato qui . Non sono anche limitati a Varnish solo servire cache quando nessun cookie sono presenti come al solito -. Si ottiene un altissimo tasso di successo della cache

Abbiamo scritto un FPC che è compatibile con Magento 1.8 nuova chiave modulo. di Brim Pagina intera cache: http://ecommerce.brimllc.com/full-page- cache-magento.html

BOOMER rende un ottimo punto di iniziare fuori basso nello stack e lavoro il vostro senso. Un FPC o vernice dovrebbe essere di circa l'ultima che fai. Facciamo controlli di rendimento e comunemente troviamo problemi con configurazioni di MySQL e APC che sono solo veramente fuori. Come InnoDB tampone dimensioni impostate al default e il database ha modo così cresciuto passato.

Si consiglia di non utilizzare alcun FPC con vernice, se non specificatamente progettati per lavorare insieme. In generale, noi non consigliamo Varnish a meno che non si dispone di una manciata di server nerboruti che sono stati tutti sintonizzati con il vostro codice di base e stanno ancora lottando per mantenere con il traffico. Aggiornamento contenuto dinamico può essere difficile con vernice specificamente quando si cerca di limitare le vostre richieste al backend Magento ea sua volta la riduzione del carico. Se si dispone di una o due teste web, i guadagni non può valere il tempo e complicazione.

Nella maggior parte dei casi una buona FPC ti porterà le prestazioni vostro bisogno, naturalmente dopo che il server e il codice di base sono stati sintonizzati. Con la nostra FPC si può ottenere sotto 15ms tempi di generazione a livello 1 di cache e sub 100ms nella cache standard. La nostra cache di livello 1 è utilizzato per i casi in cui l'utente non è connesso e non ha nulla a loro carrello in quanto non fa la perforazione. Quando una di queste condizioni è falsa la cache standard è utilizzato con il supporto completo perforazione.

Il nostro FPC ha un facile punzonatura buco integrato e funziona out of the box con tutti i blocchi di Magento standard così come eventuali blocchi personalizzati si possono avere. E 'tutto configurabile tramite il pannello di amministrazione.

mi consiglia attaccare con Redis a meno che non si hanno problemi di scala con esso. Ha supporto per i tag ed è molto più veloce di memcached con file o database come backend lento. Se si desidera che i tag coerenti e di pulizia è necessario utilizzare memcached con database quando si dispone di più teste web. Con il supporto per i tag di Redis integrato, non dovete preoccuparvi di questo. È inoltre possibile utilizzare Redis per le sessioni.

posso parlare per tutti FPC di, ma con la nostra, è possibile configurare tramite l'amministratore dove metterlo. È possibile scegliere di utilizzare la cache di Magento backend predefinito o specificare impostazioni personalizzate per utilizzare file, database, APC, Redis, Memcache, e un backend file ottimizzato.

Non c'è una risposta corretta. Un negozio dovrebbe avere sotto 3s caricamento della pagina dinamici e idealmente 1-2s caricamento della pagina dinamica, inferiore al secondo non è necessario ed è soprattutto un mercato guidato statistica. Apache è facile da imparare e difficile da far eseguire, Nginx è difficile da imparare e facile da fare eseguire, molti siti si stanno muovendo verso Nginx comunque di avere un'architettura di alta qualità sulla base di Nginx e Magento non è semplice.

cluster

multi-server Magento sono già complessa da implementare, e ancora più difficile da mantenere se non sull'architettura corretto, normalmente il lavoro con i cluster più grandi che rende tutto scorrere più agevolmente tra cui la classifica. Lo facciamo con lo standard di configurazione di installazione con lievi modifiche per medie di stabilità a lungo termine mira il caricamento della pagina dinamica 1-2s, rende tutto molto più semplice per la manutenzione.

Vernice può essere un FPC, CDN, tra gli altri, ma nel tuo caso è meglio pensare ad esso come un FPC. Un FPC consente più visitatori sul server e fornisce una consegna più rapida statica di cui Varnish è uno di questi strumenti, tuttavia ci sono diversi problemi con esso, tra cui contenuto dinamico, il controllo delle scorte, i prezzi. La risposta si riduce a come la vostra azienda è strutturata, come è caricato i dati, la frequenza, il tipo di hosting e di più, semplicemente è la tua struttura interessata, fornendo contenuti statici ai visitatori. È tecnicamente possibile attenuare gran parte di questo con FPC config tuttavia complica l'ambiente delle imprese, da un punto di vista imprenditore non può produrre un ritorno sugli investimenti equilibrato.

La FPC è l'ultima parte se avete 3s sub o di carico migliore dinamica, l'architettura in grado di gestire beadth nelle richieste visitatori come questo influenza classifica, assorbire la commercializzazione e vacanze picchi, e hanno il budget per aggiungere complessità in architettura server - di hosting dovrebbe essere 0,5-1% del fatturato per le piccole imprese, la maggior parte a conduzione sostanzialmente sotto questo causando molti problemi di business indiretto.

Il motivo per cui non hai trovato una risposta definitiva è dovuta al fatto che tali questioni richiedono mesi di risposta in quanto sono di tipo qualitativo (basata business) che richiedono le informazioni di una società non vorrebbe postare pubblicamente, le velocità di caricamento delle pagine sono di tipo quantitativo (tecniche basate) che può essere publicy inviato, è come la vostra combinare le due cose che rende la soluzione.

È possibile utilizzare questa Magento pagina di cache che si adatta alle vostre esigenze ed è simile a vernice. E 'utilizzato da molti dei più grandi negozi Magento. Alcune caratteristiche:

  1. Come per unghie, che non fa uso di una connessione al database per il 90% delle richieste. Di conseguenza, è estremamente veloce
  2. Si ha la capacità di pagine auto-filo quando le cose come le variazioni di stock di prodotto ed è molto bravo in questo
  3. Si tratta di una cache a più livelli in modo che supporta anche la perforazione quando gli utenti login (queste richieste richiedono l'uso di database)

Come una cache multilivello è scalabile anche per i negozi di traffico più elevati ed è stato utilizzato su molti siti estremamente alto traffico che ricevono traffico di punta, come i negozi di essere disponibili sul Shark Tank (tv show)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a magento.stackexchange
scroll top