¿Cómo utilizar la base de datos como slow_backend en lugar de archivos en Magento EE 1.12?


14

En Magento EE 1.12.0.0, parece que no importa a qué cambios de configuración realice app/etc/local.xml, la caché de archivos predeterminada se sigue utilizando (lo que se evidencia al var/cache/llenar siempre).

Expectativa

  • Memcached se usa como fast_backend.
  • La base de datos se usa como slow_backend.
  • La memoria caché de archivos no se utiliza en absoluto (es decir var/cache/, siempre debe estar vacía).

Salida real

  • Memcached se usa como fast_backend.
  • La base de datos no se utiliza en absoluto.
  • Se está utilizando el caché de archivos.

Procedimiento de prueba

  1. Haga el cambio de configuración a app/etc/local.xml.
  2. Reinicie Memcached y Apache (solo por si acaso y está en mi caja de desarrollo local para que yo también pueda).
  3. Borre la caché del archivo ( rm -rf var/cache/*).
  4. Actualiza la página de inicio.
  5. Verifique el contenido del archivo caché ( ls var/cache).
  6. Entristecerse y volver al # 1 con un cambio de configuración diferente.

La configuración

El contenido de mi app/etc/local.xmles el siguiente:

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


Nunca encontré una solución a este problema; sin embargo, como he trabajado en proyectos adicionales de Magento bajo el empleo de una compañía diferente y he usado configuraciones similares a las descritas aquí, me inclino a creer que fue un problema con uno de: 1. Esa instalación de Magento (mala modificaciones / módulos / etc.) 2. Los scripts de aprovisionamiento de la compañía para sus servidores se adaptaron mal de Drupal y se perdieron algunas cosas 3. Acto de Dios / Naturaleza 4. (muy probablemente) Es Magento Independientemente, @fantasticrice dio una gran respuesta que debería ayuda a Googlers, para que obtenga el premio!
Robr3rd

Respuestas:


5

Creo que ese no es el formato correcto para los nodos de caché. Entiendo que todas las configuraciones de caché deben estar anidadas dentro del <cache>nodo. Entonces, para usar caché de dos niveles con base de datos memcached + sería algo como esto:

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

Tenga en cuenta que <full_page_cache>puede configurarse exactamente de la misma manera y puede usar diferentes configuraciones si lo desea. Son solo dos instancias de caché separadas.

Así como una nota al margen, yo altamente recomendar el uso de Redis lugar. Admite etiquetas, por lo que se puede usar como caché de un solo nivel y funcionará mucho mejor que la base de datos memcached + de dos niveles.


3
Secundo la defensa de Redis. El backend lento de db causa más daño del que ayuda.
philwinkle

También probé esa configuración (en realidad es con lo que comencé; la que publiqué se sugirió como alternativa ya que lo anterior no funcionaba). ¿Se <full_page_cache>podría estar llenando var/cache? Tengo entendido que en su lugar utiliza var/full_page_cache. También he intentado usar el mismo <cache>...</cache>(su estilo) por <full_page_cache>y en enterprise.xmlvano. En lo que respecta a Redis, desafortunadamente se requiere usar el backend DB.
Robr3rd

Acabo de notar que tienes <cache>...<servers>...<server1>...</server1>. ¿Es importante el 1en server1?
Robr3rd

@RobertRobinson - no, no es importante en absoluto excepto como una forma de definir múltiples nodos debajo <servers>. Puede usar foo, bar, baz tan fácilmente como server1, server2, server3. Tiene razón en que la full_page_cacheinstancia obtiene su propio subdirectorio varsi está usando archivos.
fantasticrice

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.