Magento Automatic Caching Insight


16

Stiamo eseguendo Magento EE 1.11 con memcache. 2 GB per server memcahce, 4 GB totali. Abbiamo circa 240.000 prodotti.

  • Ram disponibile: 6 GB
  • Core: 16
  • Discussioni: 32

Ecco il problema, vengono aggiunti più nuovi prodotti e le modifiche ai prodotti si verificano su base giornaliera e, naturalmente, ogni volta che un nuovo prodotto viene aggiunto / modificato nel back-end, la cache viene invalidata, in particolare la "cache a pagina intera".

Quando Magentos Auto Cache Generation è abilitata, sono necessari circa 2 giorni per creare la cache, con 8 thread assegnati al crawler. Dopo 2 giorni il memcache si sposta intorno a ~ 2 GB separati tra i due dischi ram.

Il problema è che quando i prodotti vengono modificati quotidianamente, la cache viene invalidata e non appena la 'cache della pagina intera' viene aggiornata, quei 2 GB di cache tornano al punto di partenza 1, e il ciclo viscoso della cache di Magentos Auto si riavvia. Ora, non solo la cache torna a 0, ma l'utilizzo della CPU raggiunge il 90% e il sito Web si trasforma in un gioco in attesa di 5-10 + secondi e puoi semplicemente dimenticare di provare a richiedere un prodotto con oltre 100 varianti, se è non memorizzato nella cache, ci vorranno pochi minuti per caricare la prima volta, è ridicolo.

Quindi, le mie domande alla comunità.

  • C'è un modo per Magento di "aggiornare" automaticamente la cache se invalidata, senza ricostruire l'intera cache e iniziare da 0? So quando la cache viene invalidata che Magento sa che qualcosa è cambiato, ma non esattamente dove si trova nella cache (correggimi se sbaglio). Ci sono moduli / configurazioni là fuori per bypassare la ricostruzione dell'intera cache?

Nella nota a margine, stiamo usando il modulo LightSpeed ​​di Tiny Bricks.

  • Magentos Automatic Cache Generation può essere controllato nel tempo con un cronjob? Di ', per iniziare a gattonare alle 22:00 - 6:00.

  • Quale sarebbe il modo migliore per affrontare questa situazione? Come capisci ricostruire una cache che è in gigabyte ogni giorno non è accettabile.


1
Mi sento così sciocco in questo momento che avrei dovuto pubblicare più dettagli sul server. Mi è stata appena presentata la configurazione del server quando ho posto la domanda. Ma ecco la configurazione attuale: 2 server, identici. Uno con Apache e un MySQL in esecuzione, entrambi con 64 GB di RAM seduti su 2 CPU AMD Opteron 6276 con 32 core, 32 thread. Dopo molte letture ho scavato nella configurazione del server e mi sono reso conto che molte cose erano configurate male, specialmente Magentos cache. Avevano installato APC da 2 GB come backend e memcache da 4 GB per il backend lento su una configurazione 1 + 1 e un sacco di altre strane configurazioni.
Oleg,

Forse perché quando si è passati a EE le dimensioni del catalogo erano molto più ridotte, non sono sicuro. Inoltre, non sono ancora sicuro di come sia installato il server sql perché non ho ancora richiesto l'accesso. Quindi sono sicuro che sia un altro enigma. Volevo solo ringraziare Sonassi per aver dedicato del tempo a rispondere e per aver fornito prove / indicazioni eccezionali, tutto aiuta!
Oleg,

Per coloro che si imbattono in questo thread qui ci sono link molto utili per impostare la cache di Magentos : magebase.com/magento-tutorials/improving-the-file-cache-backend e specialmente *** -> nbs-system.co.uk/ blog-2 / magento-optimisation-howto-en.html e assicurati di leggere Magento Wiki e Magento White Pages.
Oleg,

Risposte:


14

Non hai abbastanza RAM

Abbiamo circa 240k prodotti
Ram disponibili: 6GB
Discussioni: 32

Non hai abbastanza RAM per la quantità di prodotti che hai. Come regola generale, consigliamo almeno 2-4 GB di RAM per core logico.

Se si mappa il possibile utilizzo della memoria:

  • 64 thread PHP con a max_memory ~ 768 MB = 24 GB
  • 240.000 prodotti probabilmente significheranno circa 15 GB di spazio sul tavolo InnoDB
  • 64 thread PHP garantiranno circa 128 connessioni MySQL, in genere questo ha un costo di circa 200 MB per connessione minima
  • Lo storage back-end per 240.000 prodotti in Redis e lzfcompressi consumerà ancora circa 6 GB di RAM

Quindi il totale finora è di 70 GB di RAM impegnata - non abbiamo nemmeno menzionato il sistema operativo ecc.

Il tuo hardware è terribilmente sottostimato . Suggerirei di leggere questo articolo di configurazione del server Magento per avere un'idea di come procedere.

Memcached non supporta i tag cache

Se stai usando Memcached (non è un problema, le sue prestazioni molto alte), allora stai memorizzando i tag cache o no. Se non hai slow_backenddefinito - quindi non stai memorizzando i tag, il che significa sostanzialmente che la tua cache non può discriminare tra i diversi tipi di cache - quindi non sarai in grado di scaricarli in modo indipendente.

Leggi questo, http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/

Consigliamo vivamente di passare a Redis. Ha le sue stranezze e ha bisogno di una messa a punto significativa per i negozi più grandi. Ma nel complesso funzionerà leggermente meglio di Memcached con il vero vantaggio del supporto di tag cache.

404 e FPC

FPC ha un vero problema, infatti, tutti i motori di cache hanno un problema con 404s. Il motivo è che tutti i vecchi URL ancora sottoposti a scansione o collegati finiranno su una pagina che deve scorrere attraverso l'intera core_url_rewritetabella, provare a trovare una corrispondenza con tutti i router e gli spazi dei nomi definiti prima di rinunciare e caricare un 404.

Quindi memorizza nella cache una risorsa che non ha alcun valore e consumerà spazio nella memoria cache. Probabilmente scoprirai che gran parte della tua memoria Memcached viene effettivamente consumata da 404 contenuti.

Con cataloghi di grandi dimensioni (240k prodotti), avrai sicuramente la tua giusta quota di turnover del prodotto, e quindi, cambiamenti negli URL e, successivamente, molti 404.

FPC non valido o pulito

Al momento - e per impostazione predefinita - il comportamento di FPC è quello di pulire la cache in caso di modifiche, piuttosto che invalidare semplicemente la voce della cache. Abbiamo scritto un'estensione per modificare questo comportamento affinché un negozio EE esegua esattamente ciò di cui hai bisogno.

Ecco una breve patch per darti un'idea di come risolvere il tuo problema.

app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
             <observers>
                 <enterprise_pagecache>
                     <class>enterprise_pagecache/observer</class>
-                    <method>cleanCache</method>
+                    <method>invalidateCache</method>
                 </enterprise_pagecache>
             </observers>
         </catalogrule_after_apply>

Non eseguire un cingolato

Se hai un discreto margine di manovra, non ti consigliamo di eseguire lo strumento di scansione, che genera un carico non necessario. Le persone / i robot / i crawler che visitano il sito devono mantenere la cache innescata.

Ma per rispondere alla tua domanda, se guardi nel file di configurazione menzionato sopra, vedi la pianificazione cron che è stata definita per la finestra di ricerca per indicizzazione.

Se puoi permetterti contenuti non aggiornati

E alla fine, se ne hai abbastanza RAM. Potresti trarre vantaggio dall'aumento del TTL dei contenuti archiviati in FPC per mantenere i dati memorizzati nella cache più a lungo.

Nel <full_page_cache>tag nel tuo ./app/etc/local.xmlappena definito

<lifetimelimit>86400</lifetimelimit>

La durata è definita in secondi. Devi trovare un equilibrio tra freschezza dei contenuti, prestazioni e quantità di spazio di archiviazione effettivamente disponibile.

Perché stai utilizzando un'estensione di memorizzazione nella cache di terze parti con EE

Stai pagando un premio per FPC - il che mi fa male dire, è molto buono. Quindi perché stai eseguendo alternative di terze parti sopra le righe. Rimuoverlo.

Detto in questo modo. Se la tua auto funzionasse male, aggiungeresti semplicemente un altro motore nel bagagliaio per compensare; o semplicemente riparare il motore già lì?


-1

Ti capiamo molto bene! Aggiungiamo nuovi o cambiamo i nostri prodotti ogni giorno e modifichiamo anche i blocchi statici. Quindi eravamo pieni di cache Magento non valida e questa costante passava a Sistema -> Gestione cache. Odiavamo la necessità di aggiornare manualmente i tipi di cache non validi.

Quindi abbiamo installato la nuova estensione Magento Optimizer . Questo modulo automatizza questo processo. Aggiorna la invalidata / tutti i tipi di cache o scarica la memoria cache Magento alla frequenza specificata. È stato un vero sollievo per tutto il nostro team!

Un'altra grande caratteristica di questa estensione è che pulisce i file di sessione e i rapporti di errore che sono più vecchi di X giorni. Tutti sanno che la dimensione delle directory var / session e var / report può aumentare in gigabyte e il numero di questi file può superare le centinaia. Quindi ora per rallentare le prestazioni del sito Web, abbiamo impostato Magento Optimizer una volta e ci siamo dimenticati del periodico aggiornamento di queste directory.

Magento è noto per aver unito un carrello abbandonato a quello attuale quando i clienti tentano di accedere. Dall'esperienza dei clienti e dal punto di vista della fedeltà, è distruttivo. Il modulo Ottimizzatore Magento elimina automaticamente i carrelli abbandonati più vecchi di X giorni. È possibile utilizzare questa funzione anche in fase di vendita e limitare il tempo per i carrelli abbandonati esistenti.


1
James hai qualche connessione con questo modulo? Sembri entusiasta.
Parhamr,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.