Comment utiliser la base de données en tant que slow_backend au lieu de fichiers dans Magento EE 1.12?


14

Dans Magento EE 1.12.0.0 Il semblerait que peu importe les modifications de configuration que j'apporte app/etc/local.xml, le cache de fichiers par défaut continue d'être utilisé (ce qui est attesté par un var/cache/remplissage permanent).

Attente

  • Memcached est utilisé comme fast_backend.
  • La base de données est utilisée comme slow_backend.
  • Le cache de fichiers n'est pas utilisé du tout (c'est-à-dire qu'il var/cache/doit toujours être vide).

Sortie réelle

  • Memcached est utilisé comme fast_backend.
  • La base de données n'est pas utilisée du tout.
  • Le cache de fichiers est utilisé.

Procédure de test

  1. Modifiez la configuration en app/etc/local.xml.
  2. Redémarrez Memcached et Apache (juste pour faire bonne mesure et c'est sur ma boîte de développement locale donc je peux aussi bien).
  3. Vider le cache de fichiers ( rm -rf var/cache/*).
  4. Actualisez la page d'accueil.
  5. Vérifiez le contenu du cache de fichiers ( ls var/cache).
  6. Devenez attristé et revenez au n ° 1 avec un changement de configuration différent.

La config

Le contenu de mon app/etc/local.xmlest le suivant:

<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>


Je n'ai jamais trouvé de solution à ce problème; cependant, comme j'ai depuis travaillé sur des projets Magento supplémentaires à l'emploi d'une autre société et que j'ai utilisé des configurations similaires à celles décrites ici, je suis enclin à croire qu'il s'agissait d'un problème avec: 1. Cette installation de Magento (mauvaise modifications / modules / etc) 2. Les scripts de provisioning de l'entreprise pour leurs serveurs étant mal adaptés de Drupal et certaines choses ont été manquées 3. Act of God / Nature 4. (très probablement) C'est Magento Quoi qu'il en soit, @fantasticrice a donné une excellente réponse qui devrait aider les Googlers, alors il obtient le prix!
Robr3rd

Réponses:


5

Je pense que ce n'est pas le bon format pour les nœuds de cache. Ma compréhension est que tous les paramètres de cache doivent être imbriqués dans le <cache>nœud. Donc, pour utiliser le cache à deux niveaux avec la base de données memcached +, ce serait quelque chose comme ceci:

<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>

Gardez à l'esprit qu'il <full_page_cache>peut être configuré exactement de la même manière et peut utiliser différents paramètres si vous le souhaitez. Ce ne sont que deux instances de cache distinctes.

Juste comme note latérale, je recommanderais fortement d' utiliser Redis à la place. Il prend en charge les balises, il peut donc être utilisé comme cache à un niveau et il fonctionnera beaucoup mieux que la base de données memcached + à deux niveaux.


3
J'appuie le plaidoyer pour Redis. Le backend lent db cause plus de mal qu'il n'aide.
philwinkle

J'ai également essayé cette configuration (c'est en fait ce que j'ai commencé - celle que j'ai publiée a été suggérée comme alternative car ce qui précède ne fonctionnait pas). Serait-il <full_page_cache>possible de remplir var/cache? C'est ma compréhension qu'il utilise à la place var/full_page_cache. J'ai également essayé d'utiliser le même <cache>...</cache>(votre style) pour <full_page_cache>et en enterprise.xmlvain. En ce qui concerne Redis, malheureusement, l'utilisation du backend DB est la condition requise.
Robr3rd

Je viens de remarquer que vous l'avez fait <cache>...<servers>...<server1>...</server1>. Est -ce le 1dans server1important?
Robr3rd

@RobertRobinson - non, pas important du tout sauf comme un moyen de définir plusieurs nœuds sous <servers>. Vous pouvez utiliser foo, bar, baz aussi facilement que server1, server2, server3. Vous avez raison, cette full_page_cacheinstance obtient son propre sous-répertoire varsi elle utilise des fichiers.
fantasticrice

@RobertRobinson - vous pourriez être intéressé par cette extension pour voir l'état de la configuration de Magento .
fantasticrice
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.