Come usare Database come slow_backend invece di File in Magento EE 1.12?


14

In Magento EE 1.12.0.0 Sembrerebbe che, indipendentemente dalle modifiche alla configurazione apportate app/etc/local.xml, la cache di file predefinita continua a essere utilizzata (come evidenziato dal var/cache/riempimento sempre).

aspettativa

  • Memcached è usato come fast_backend.
  • Il database viene utilizzato come slow_backend.
  • La cache dei file non viene utilizzata affatto (ovvero var/cache/deve essere sempre vuota).

Uscita effettiva

  • Memcached è usato come fast_backend.
  • Il database non è utilizzato affatto.
  • La cache dei file è in uso.

Procedura di test

  1. Apporta la modifica della configurazione a app/etc/local.xml.
  2. Riavvia Memcached e Apache (solo per una buona misura ed è sulla mia casella di sviluppo locale, quindi posso anche io).
  3. Cancella la cache dei file ( rm -rf var/cache/*).
  4. Aggiorna la home page.
  5. Controlla il contenuto della cache dei file ( ls var/cache).
  6. Diventa rattristato e torna al numero 1 con un diverso cambio di configurazione.

The Config

Il mio contenuto app/etc/local.xmlè il seguente:

<config>
    <global>
        <install>
            <date><![CDATA[{{actual_data}}]]></date>
        </install>
        <crypt>
            <key><![CDATA[{{actual_data}}]]></key>
        </crypt>
        <disable_local_modules>false</disable_local_modules>
        <resources>
            <db>
                <table_prefix><![CDATA[]]></table_prefix>
            </db>
            <default_setup>
                <connection>
                    <host><![CDATA[{{actual_data}}]]></host>
                    <username><![CDATA[{{actual_data}}]]></username>
                    <password><![CDATA[{{actual_data}}]]></password>
                    <dbname><![CDATA[{{actual_data}}]]></dbname>
                    <initStatements><![CDATA[SET NAMES utf8]]></initStatements>
                    <model><![CDATA[mysql4]]></model>
                    <type><![CDATA[pdo_mysql]]></type>
                    <pdoType><![CDATA[]]></pdoType>
                    <active>1</active>
                </connection>
            </default_setup>
        </resources>
        <session_save><![CDATA[db]]></session_save>
        <cache>memcached</cache>
        <slow_backend>database</slow_backend>
        <slow_backend_store_data>1</slow_backend_store_data>
        <memcached>
            <servers>
                <server>
                    <host><![CDATA[{{actual_data}}]]></host>
                    <port><![CDATA[{{actual_data}}]]></port>
                    <persistent><![CDATA[0]]></persistent>
                    <weight><![CDATA[2]]></weight>
                    <timeout><![CDATA[10]]></timeout>
                    <retry_interval><![CDATA[10]]></retry_interval>
                    <status><![CDATA[]]></status>
                </server>
            </servers>
            <compression><![CDATA[0]]></compression>
            <cache_dir><![CDATA[]]></cache_dir>
            <hashed_directory_level><![CDATA[]]></hashed_directory_level>
            <hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
            <file_name_prefix><![CDATA[]]></file_name_prefix>
        </memcached>
    </global>
    <admin>
        <routers>
            <adminhtml>
                <args>
                    <frontName><![CDATA[admin]]></frontName>
                </args>
            </adminhtml>
        </routers>
    </admin>
</config>


Non ho mai trovato una soluzione a questo problema; tuttavia, come allora ho lavorato su altri progetti Magento sotto alle dipendenze di una società diversa e hanno utilizzato le configurazioni simili a quelle descritte qui, sono propenso a credere che si trattava di un problema con uno di: 1. Che l'installazione di Magento (Bad modifiche / moduli / ecc.) 2. Gli script di provisioning dell'azienda per i loro server sono stati scarsamente adattati da Drupal e alcune cose sono state perse 3. Atto di Dio / Natura 4. (molto probabilmente) È Magento Indipendentemente da ciò, @fantasticrice ha dato un'ottima risposta che dovrebbe aiutare i googler, così ottiene il premio!
Robr,

Risposte:


5

Penso che non sia il formato giusto per i nodi della cache. La mia comprensione è che tutte le impostazioni della cache dovrebbero essere nidificate all'interno del <cache>nodo. Quindi per usare la cache a due livelli con memcached + database sarebbe qualcosa del genere:

<cache>
    <backend>memcached</backend>
    <slow_backend>database</slow_backend>
    <memcached>
        <servers>
            <server1>
                <host>...</host>
                <port>11211</port>
                <persistent>1</persistent>
                <weight>2</weight>
                <timeout>10</timeout>
                <retry_interval>10</retry_interval>
                <status/>
            </server1>
            ...
        </servers>
        <compression>0</compression>
        <cache_dir/>
        <hashed_directory_level/>
        <hashed_directory_umask/>
        <file_name_prefix/>
    </memcached>
</cache>

Tieni presente che <full_page_cache>può essere configurato esattamente allo stesso modo e, se lo desideri, puoi utilizzare impostazioni diverse. Sono solo due istanze cache separate.

Proprio come nota a margine, consiglio vivamente di usare Redis . Supporta i tag, quindi può essere utilizzato come cache a livello singolo e funzionerà molto meglio di memcached + database a due livelli.


3
Secondo il patrocinio per Redis. Il db slow backend provoca più danni di quanti ne possano aiutare.
Filwinkle,

Ho anche provato quella configurazione (in realtà è quello che ho iniziato con - quello che ho pubblicato è stato suggerito come alternativa poiché quanto sopra non funzionava). Sarebbe <full_page_cache>forse riempire var/cache? Comprendo che invece utilizza var/full_page_cache. Ho anche provato a usare lo stesso <cache>...</cache>(il tuo stile) per <full_page_cache>e enterprise.xmlsenza risultati. Per quanto riguarda Redis, purtroppo è necessario utilizzare il backend DB.
Robr3rd

Ho appena notato che hai <cache>...<servers>...<server1>...</server1>. È l' 1in server1importante?
Robr3rd

@RobertRobinson - no, non è affatto importante se non come un modo per definire più nodi in <servers>. Puoi usare foo, bar, baz con la stessa facilità di server1, server2, server3. Hai ragione che full_page_cachequell'istanza ottiene la sua sottodirectory sotto varse sta usando i file.
fantasticrice,

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.