Información de almacenamiento en caché automática de Magento

Estamos ejecutando Magento EE 1.11 con memcache. 2GB por servidor memcahce, 4GB en total. Tenemos alrededor de 240k productos.

• RAM disponible: 6GB
• Núcleos: 16
• Subprocesos: 32

Aquí está el trato, se agregan más productos nuevos y se producen cambios en los productos a diario y, por supuesto, cada vez que se agrega / modifica un nuevo producto en el back-end, el caché se invalida, específicamente el 'Caché de página completa'.

Cuando la generación automática de caché de Magentos está habilitada, la creación de la caché demora aproximadamente 2 días, con 8 subprocesos asignados al rastreador. Después de 2 días, la memoria caché flota alrededor de ~ 2 GB separados entre los dos discos ram.

El problema es que, cuando los productos se modifican diariamente, el caché se invalida y tan pronto como se actualiza 'Full Page Cache' esos 2GB de caché vuelven al punto uno, 0, y el ciclo viscoso del caché Magentos Auto comienza de nuevo. Ahora, no solo el caché vuelve a 0, sino que el uso de la CPU aumenta al 90% y el sitio web se convierte en un juego de espera de 5-10 segundos y puede olvidarse de intentar solicitar un producto con más de 100 variaciones, si es no almacenado en caché, tardaría unos minutos en cargarse la primera vez, es ridículo.

Entonces, mis preguntas a la comunidad.

• ¿Hay alguna manera de que Magento "actualice" automáticamente el caché si se invalida, sin reconstruir todo el caché y comenzar desde 0? Sé que cuando se invalida el caché, Magento sabe que algo ha cambiado, pero no exactamente en qué parte del caché (corrígeme si me equivoco). ¿Existen módulos / configuraciones para evitar reconstruir todo el caché?

En la nota al margen, estamos utilizando el módulo Tiny Bricks LightSpeed.

• ¿Puede Magentos Automatic Cache Generation ser controlado por tiempo con un cronjob? Digamos, para comenzar a gatear a las 10pm - 6am.

• ¿Cuál sería la mejor manera de abordar esta situación? Como entiendes, reconstruir un caché que está en gigabytes todos los días simplemente no es aceptable.

No tienes casi suficiente RAM

Tenemos alrededor de 240k productos
RAM disponibles: 6GB
Subprocesos: 32

No tiene suficiente RAM para la cantidad de productos que tiene. Como regla general, recomendamos al menos 2-4 GB de RAM por núcleo lógico.

Si asigna su posible uso de memoria:

• 64 max_memorysubprocesos PHP con un ~ 768MB = 24GB
• 240,000 productos probablemente significarán alrededor de 15 GB de espacio de tabla InnoDB
• 64 subprocesos PHP garantizarán alrededor de 128 conexiones MySQL, generalmente esto tiene un costo de aproximadamente 200 MB por conexión mínima
• Almacenamiento de back-end para 240,000 productos en Redis Y lzfcomprimido: aún consumirá aproximadamente 6 GB de RAM

Entonces, el total hasta ahora es de 70 GB de RAM comprometida; ni siquiera hemos mencionado el sistema operativo, etc.

Su hardware está terriblemente subespecificado . Sugeriría leer este artículo de configuración del servidor Magento para conocer un poco sobre cómo progresar.

Memcached no admite etiquetas de caché

Si está utilizando Memcached (no es un problema, es un rendimiento muy alto), entonces está almacenando etiquetas de caché o no. Si no tiene un slow_backenddefinido, entonces no está almacenando etiquetas, lo que básicamente significa que su caché no puede discriminar entre ninguno de los diferentes tipos de caché, por lo que no podrá vaciarlos de forma independiente.

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

Sugerimos encarecidamente cambiar a Redis. Tiene sus peculiaridades y necesita un ajuste significativo para tiendas más grandes. Pero en general funcionará un poco mejor que Memcached con el beneficio real de la compatibilidad con etiquetas de caché.

404's y FPC

FPC tiene un problema real, de hecho, todos los motores de almacenamiento en caché tienen un problema con los 404. La razón es que las URL antiguas que aún se rastrean o vinculan aterrizarán en una página que tiene que recorrer en iteración toda la core_url_rewritetabla, tratar de encontrar una coincidencia con todos los enrutadores y espacios de nombres definidos antes de finalmente abandonar y cargar un 404.

Luego, almacena en caché un recurso que no tiene valor y consumirá espacio en el almacenamiento de su caché. Probablemente encontrará que una gran proporción de su almacenamiento Memcached está siendo consumida por el contenido 404.

Con grandes catálogos (productos de 240k), sin duda tendrá una buena parte de la rotación de productos y, por lo tanto, cambios en las URL y, posteriormente, en muchos 404.

Invalidar FPC vs. Limpiar

Por el momento, y de manera predeterminada, el comportamiento de FPC es limpiar el caché de los cambios, en lugar de simplemente invalidar la entrada del caché. Escribimos una extensión para alterar este comportamiento para que una tienda EE haga exactamente lo que usted requirió.

Aquí hay un parche rápido para darle una idea de cómo resolver su 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>

No corras un rastreador

Si tiene una pisada decente, no recomendamos ejecutar la herramienta de rastreo, ya que genera una carga innecesaria. Las personas / bots / rastreadores que navegan por el sitio deben mantener el caché preparado.

Pero para responder a su pregunta, si mira en el archivo de configuración mencionado anteriormente, verá la programación cron que se ha definido para la ventana de exploración de rastreo.

Si puede permitirse el contenido obsoleto

Y finalmente, si tienes suficiente RAM. Bien podría beneficiarse al aumentar el TTL del contenido almacenado en FPC, para mantener sus datos almacenados en caché con vida por más tiempo.

En la <full_page_cache>etiqueta en su ./app/etc/local.xmlsolo definir

<lifetimelimit>86400</lifetimelimit>

La vida útil se define en segundos. Debe lograr un equilibrio entre la actualización del contenido, el rendimiento y la cantidad de espacio de almacenamiento que realmente tiene disponible.

¿Por qué está utilizando una extensión de almacenamiento en caché de terceros con EE

Estás pagando una prima por FPC, lo que me duele decir que es muy bueno. Entonces, ¿por qué está ejecutando alternativas de terceros en la parte superior? Quitarlo

Ponlo de esta manera. Si su automóvil funcionara mal, ¿agregaría otro motor en el maletero para compensarlo? o simplemente arreglar el motor ya allí?

¡Te entendemos muy bien! Añadimos nuevos o cambiamos nuestros productos todos los días y también modificamos bloques estáticos. Así que estábamos llenos de caché Magento invalidado y esta constante yendo a Sistema -> Administración de caché. Odiamos la necesidad de actualizar los tipos de caché invalidados manualmente.

Luego instalamos la nueva extensión Magento Optimizer . Este módulo automatiza este proceso. Actualiza los tipos de caché invalidados / todos o vacía el almacenamiento de caché de Magento a la frecuencia especificada. ¡Fue un verdadero alivio para todo nuestro equipo!

Una gran característica más de esta extensión es que limpia los archivos de sesión y los informes de errores que tienen más de X días. Todo el mundo sabe que el tamaño de los directorios var / session y var / report puede crecer en gigabytes y la cantidad de estos archivos puede exceder los cien. Entonces, para reducir el rendimiento del sitio web, configuramos Magento Optimizer una vez y nos olvidamos de la actualización periódica de estos directorios.

Magento es conocido por fusionar un carrito abandonado con el actual cuando los clientes intentan iniciar sesión. Desde el punto de vista de la experiencia y la lealtad de los clientes, es destructivo. El módulo Magento Optimizer elimina automáticamente los carros abandonados anteriores a X días. También puede usar esta función en el momento de las ventas y limitar el tiempo de los carros abandonados existentes.