Wie verwende ich Database als slow_backend anstelle von Files in Magento EE 1.12?


14

In Magento EE 1.12.0.0 scheint es so zu sein app/etc/local.xml, dass der Standard- Dateicache weiterhin verwendet wird, egal an welcher Konfiguration ich Änderungen vornehme var/cache/.

Erwartung

  • Memcached wird als fast_backend verwendet.
  • Die Datenbank wird als slow_backend verwendet.
  • Der Dateicache wird überhaupt nicht verwendet ( var/cache/sollte also immer leer sein).

Tatsächliche Ausgabe

  • Memcached wird als fast_backend verwendet.
  • Die Datenbank wird überhaupt nicht verwendet.
  • Der Dateicache wird verwendet.

Testverfahren

  1. Nehmen Sie die Konfigurationsänderung zu vor app/etc/local.xml.
  2. Starten Sie Memcached und Apache neu.
  3. Leeren Sie den Dateicache ( rm -rf var/cache/*).
  4. Aktualisieren Sie die Homepage.
  5. Überprüfen Sie den Inhalt des Dateicaches ( ls var/cache).
  6. Sei traurig und kehre mit einer anderen Konfigurationsänderung zu # 1 zurück.

Die Konfig

Der Inhalt von my app/etc/local.xmlist wie folgt:

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


Ich habe nie eine Lösung für dieses Problem gefunden. Da ich jedoch seitdem in einem anderen Unternehmen an weiteren Magento-Projekten gearbeitet habe und Konfigurationen ähnlich den hier beschriebenen verwendet habe, bin ich der Ansicht, dass eines der folgenden Probleme aufgetreten ist : 1. Die Installation von Magento (schlecht Änderungen / Module / etc) 2. Die Provisioning-Skripte des Unternehmens für ihre Server wurden von Drupal schlecht angepasst und einige Dinge wurden übersehen hilf googlern, damit er den preis bekommt!
4.

Antworten:


5

Ich denke, das ist nicht das richtige Format für die Cache-Knoten. Mein Verständnis ist, dass alle Cache-Einstellungen innerhalb des <cache>Knotens verschachtelt sein sollten . Wenn Sie also einen zweistufigen Cache mit memcached + database verwenden möchten, wäre das ungefähr so:

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

Denken Sie daran, dass Sie <full_page_cache>genau so konfigurieren und auf Wunsch auch andere Einstellungen vornehmen können. Sie sind nur zwei separate Cache-Instanzen.

So wie eine Randnotiz, würde ich sehr empfehlen mit Redis statt. Es unterstützt Tags, kann also als einstufiger Cache verwendet werden und ist wesentlich leistungsfähiger als eine + zweispeicherige Datenbank.


3
Ich unterstütze das Eintreten für Redis. Das langsame Backend von db verursacht mehr Schaden als es hilft.
Philwinkle

Ich habe diese Konfiguration auch ausprobiert (eigentlich habe ich damit begonnen - die von mir veröffentlichte wurde als Alternative vorgeschlagen, da die oben genannten nicht funktionierten). Wäre das <full_page_cache>evtl. füllend var/cache? Es ist mein Verständnis, dass es stattdessen verwendet var/full_page_cache. Ich habe auch versucht, dasselbe <cache>...</cache>(deinen Stil) für <full_page_cache>und enterprise.xmlohne Erfolg zu verwenden. Für Redis ist leider die Verwendung des DB-Backends Voraussetzung.
Robr3rd

Ich habe gerade bemerkt, dass Sie haben <cache>...<servers>...<server1>...</server1>. Ist das 1in so server1wichtig?
Robr3rd

@RobertRobinson - Nein, überhaupt nicht wichtig, außer um mehrere Knoten darunter zu definieren <servers>. Sie könnten foo, bar, baz genauso einfach verwenden wie server1, server2, server3. Sie haben Recht, dass diese full_page_cacheInstanz ein eigenes Unterverzeichnis erhält, varwenn sie Dateien verwendet.
Fantasticrice

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.