2012-06-11 9 views
20

Quindi il caching, ovviamente, è ciò che più mi confonde in Magento, come per la maggior parte degli altri I sono sicuro. Attualmente uno dei siti su cui lavoriamo è Enterprise e utilizza naturalmente FPC. Il problema è che abbiamo un aggiornamento dell'inventario che viene eseguito ogni 15 minuti. Molti ordini vengono inoltrati al CSR per telefono e attraverso un catalogo in un sistema esterno al di fuori di Magento.Perché il salvataggio Magento della cache di pagine complete sul prodotto crea effettivamente una pagina non memorizzata nella cache e cosa fa l'aggiornamento poiché non è memorizzata nella cache

Ogni 15 minuti viene eseguito uno script per controllare qualsiasi inventario in quel sistema e per vedere se è diverso da quello che è in Magento. Se c'è una differenza, l'inventario viene aggiornato in Magento. Usando tutti i metodi Magento, nessun sql o qualcosa del genere.

Abbiamo sempre avuto problemi di cache e abbiamo provato tutte le ultime tecniche quando escono. L'ultimo che stiamo provando è Redis, e abbiamo avuto un buon successo su altri siti con esso. Tuttavia, stiamo ancora assistendo a un carico pazzesco sul server ed è evidente che le pagine non sono memorizzate nella cache.

Dopo aver scavato nel codice, sembra che dopo ogni salvataggio del modello o del controller del prodotto admin, viene visualizzato per vedere se la cache deve essere invalidata. Sembra che cambiando qualsiasi attributo, almeno lo spazio pubblicitario segnerà l'FPC come se fosse necessario invalidarlo.

io sono confuso su ciò che significa invalidazione, perché un po 'indietro abbiamo avuto una domanda fuori per l'assistenza clienti su qualcosa di simile e questa è stata la risposta

cache della pagina completa arriva a stato invalidato su eventuali modifiche sui prodotti, categorie, CMS anche quando lo stock è diminuito dopo una vendita.

Ora, quando la cache della pagina intera arriva allo stato invalidato, questo non significa che che qualcosa è cambiato sul frontend, tuttavia qualsiasi modifica applicata dopo l'ultimo aggiornamento non verrà mostrato sul frontend.

Tuttavia, se avere la FPC convalidato in ogni momento è un must per la logica di business si potrebbe certamente impostare l'installazione di Magento per aggiornarlo automaticamente attraverso funzionalità cron le volte che si desiderio.

Tuttavia su tutti i test che ho eseguito, su 1.9 e 1.11 Enterprise, appare quando FPC è invalidato, la risposta non viene prelevata dalla cache. Il che è contraddittorio rispetto a quello che hanno detto a riguardo semplicemente non avendo gli aggiornamenti più recenti.

C'è qualcosa che mi manca? Qualcuno ha una buona spiegazione su come funziona l'invalidazione in Magento in modo specifico per FPC o qualsiasi buon link per comprendere appieno il processo e il codice?

Si può provare da soli per qualsiasi pagina che viene memorizzata nella cache della pagina intera. Ma è a mia conoscenza che il metodo processRequest in /app/code/core/Mage/Core/Model/Cache.php dovrebbe impostare il contenuto del corpo con la risposta memorizzata nella cache e restituire true se la pagina è memorizzata nella cache.

Per testare andare in qualsiasi pagina, assicurarsi di averlo memorizzato nella cache e restituito true. Entra e modifica un prodotto, nel nostro caso la quantità. Ciò invaliderà FPC. Tuttavia ora quando carichi la pagina che è stata memorizzata nella cache prima che restituisca false in questo metodo e non sia una pagina memorizzata nella cache. Non so se questo è accurato per essere in grado di dire se una pagina è memorizzata nella cache o no, ma è qui che mi conduce la mia indagine. Perfavore, correggimi se sbaglio.

UPDATE: Con ulteriori indagini ho scoperto che quando si salva un prodotto in admin, l'azione di controllo

Mage_Adminhtml_Catalog_ProductController::saveAction()

chiamerà il seguente metodo

Mage::getModel('catalogrule/rule')->applyAllRulesToProduct($productId)

Poi nella classe Mage_CatalogRule_Model_Resource_Rule, viene chiamato il metodo applyAllRulesForDateRange che attiva l'evento

catalogrule_after_apply

cui il modulo Pagina intera cache sta osservando e sparando il metodo della cache pulita per il tag FPC. Eliminazione di tutti i record della cache FPC.

Non vedo perché questo è necessario se in precedenza la logica sta cancellando i record FPC che sono legati ai tag di prodotto e di categoria. è un insetto?

+0

so che questo non risponde direttamente alla tua domanda, ma voglio solo far notare che la tua performance non dovrebbe essere peggiore di quella che sarebbe avvenuto se tutti gli ordini fossero stati effettuati tramite Magento, poiché dopo ogni vendita il tuo stock sarebbe diminuito di conseguenza inv alidando la tua cache come fa il tuo cron job. – nachito

+0

Vero, vedo il tuo punto lì. Quindi non ha alcun senso sul motivo per cui la pagina non viene effettivamente memorizzata nella cache quando viene invalidata per la prima volta. –

+0

Questa non è la risposta che si desidera, ma ho parlato con altri sviluppatori Magento, e nessuno di noi ha avuto un vero successo con l'FPC di serie. Ci provoca solo problemi. In genere, si finisce per utilizzare Varnish o qualche altra cache del proxy inverso. Mantenerlo separato dagli interni, che sono già abbastanza complicati. –

risposta

1

FPC sta osservando i cambiamenti di inventario perché l'intento è di visualizzare esaurito per tutti i prodotti che sono stati decrementati a magazzino zero. La soluzione sarebbe quella di creare un invio di eventi quando un prodotto raggiunge lo zero anziché ogni volta che un prodotto cambia stock e riscrive FPC per osservare quell'evento anziché l'originale.

Un altro metodo sarebbe invalidare solo le porzioni di cache relative ai prodotti da aggiornare, ma si tratterebbe di un cambiamento architettonico piuttosto significativo.

0

il modulo phoenix Page Cache cancella le pagine del prodotto e le pagine delle categorie ma lascia scoperte alcune aree di invalidazione della cache. inoltre non si adatta bene ai contenuti dinamici.

forse dovresti controllare il modulo aoe_static che fa un ottimo lavoro caricando il contenuto dinamico caricando un layout predefinito e rendendo i blocchi con una chiamata ajax. questa chiamata ajax imposta anche il cookie per consentire sessioni.

devi fare attenzione utilizzando 2 moduli in una zona piuttosto difficile, forse si dovrebbe vedere questa magento open source full page cache

0

Avere una lettura di questo articolo che ho scritto su Full caching delle pagine in Magento. Evidenzia una correzione di bug che improvvisamente rende logico l'intero meccanismo di cache!

http://www.excitedcroc.com/article/why-the-magento-full-page-cache-doesnt-expire

Essenzialmente c'è un errore nel modo Magento utilizza il meccanismo di cache Zend Framework.

Il problema è che le classi della cache della libreria Zend e le classi della cache aziendale Magento utilizzano un mix di null e false nelle loro funzioni che producono il lifetime value. Poiché null! == false viene sempre utilizzata una durata predefinita di 10 giorni. Il problema deriva dalla funzione processRequestResponse in app/code/core/Enterprise/PageCache/Model/Processor.php. Poiché nessun valore di durata viene passato all'istanza cache al salvataggio, il valore predefinito è nullo.

La modifica del valore predefinito per il parametro lifetime della funzione di salvataggio di app/code/core/Mage/Core/Model/Cache.php risolverà questo problema. Basta impostarlo su false anziché su null (l'articolo collegato sopra spiega pienamente perché).

- Funzione pubblica Save ($ dati, $ id, $ tag = array(), $ lifetime = null)

+ funzione pubblica Salva dati ($, $ id, $ tags = array(), $ Lifetime = false)

+0

Lone link è considerato una risposta scarsa (si veda [faq # deletion]) poiché non ha significato da solo e ** la risorsa target non è garantita per essere attiva in futuro **. [Sarebbe preferibile] (http://meta.stackexchange.com/q/8259) includere qui le parti essenziali della risposta e fornire il link per riferimento. – j0k

+0

Aggiornamento come sopra .. –

2

Si deve creare un nuovo indicizzatore personalizzato Mage_Index_Model_Indexer_Abstract, e creare un nuovo modello di risorse metodi API con cron jobs

Problemi correlati