Caché de Magento explicado: una guía para propietarios de tiendas

La velocidad del sitio de Magento es un factor extremadamente importante para su negocio. Es un factor de clasificación y un factor que influye en las tasas de rebote y las conversiones, así como en las intenciones de los usuarios de visitar el sitio en el futuro.

Resumen del artículo [ ocultar ]

  • Factores de rendimiento del sitio web
  • Tipos de caché de Magento
    • Caché de consultas de MySQL
    • Caché de código de operación de PHP
    • caché Magento
    • Caché de página completa del lado de la aplicación
    • Caché de página completa del lado del servidor
  • Por último, ¿Me va a ayudar Full Page Cache?
  • ¿Por qué Amasty FPC no funciona con Varnish?

Factores de rendimiento del sitio web

Para lograr que su tienda Magento sea más rápida, puede utilizar varios métodos, que se pueden dividir en tres categorías generales:

  • Actualización del servidor
  • Optimización de código
  • almacenamiento en caché

Cada una de estas variantes tiene sus pros y sus contras.

La actualización del servidor puede aumentar el rendimiento de un sitio en poco tiempo, mientras que se requieren costos relativamente pequeños. En realidad, en algunos casos, los resultados serán menos impresionantes de lo que espera. Por lo general, está conectado con algunas extensiones desordenadas; su rendimiento sufre problemas de código, no de los recursos del servidor.

He conocido tiendas, donde los problemas de código conducen a fallas en el pago cada dos veces, mientras que se asignaron 3072M para el límite de memoria [sic]. En este caso, la actualización del servidor no ayudará en absoluto a la situación, tal vez solo posponga la falla de pago por unos segundos.

La optimización del código realmente puede ayudar en algunos problemas fundamentales, pero por lo general sus costos pueden ser bastante significativos. Por supuesto, no estamos hablando de un problema o error trivial aquí.

Varios métodos de almacenamiento en caché sin duda acelerarán muchas operaciones, y también proporcionarán aceleración múltiple para solicitar páginas estáticas. O incluso dinámicos, siempre que se utilice el soporte de ‘perforación’. Esta tecnología se denomina bloque ESI, bloques dinámicos, etc.

Desarrollaré el tema del almacenamiento en caché en este artículo y espero que esta información sea útil para los propietarios de tiendas.

Tipos de caché de Magento

Se pueden destacar varios tipos de almacenamiento en caché de Magento:

  • Caché de consultas de MySQL
  • Caché de código de operación de PHP
  • caché Magento
  • caché de página completa del lado de la aplicación
  • caché de página completa del lado del servidor

Ahora repasaremos cada uno de los tipos de almacenamiento en caché.

Caché de consultas de MySQL

Este tipo de almacenamiento en caché de Magento guarda los resultados de las ejecuciones de consultas de la base de datos. El caché de consultas de MySQL puede mejorar el rendimiento de ciertas aplicaciones, donde la lectura de datos prevalece sobre agregarlos o actualizarlos. Puede encontrar muchas recomendaciones para usar este tipo de caché e incluso aumentar su tamaño. Según mi experiencia, esta táctica puede influir negativamente en el rendimiento de la base de datos en muchas configuraciones modernas. El problema es que la memoria caché de consultas de MySQL se escala de manera deficiente en arquitecturas multinúcleo y conduce a una ejecución lenta de las consultas. Puede obtener más detalles sobre posibles problemas aquí.

Caché de código de operación de PHP

Ya hemos mencionado este tipo de caché de Magento en uno de nuestros artículos anteriores . A partir de hoy, las herramientas más populares aquí son APC, Xcache, Zend Opcache y eAccelerator. Si está utilizando PHP 5.5.x, le recomiendo que se adhiera a Zend Opcache; si usa PHP 5.3/5.4, es mejor optar por APC 3.1.13. Nota: olvídese de las versiones anteriores de APC, porque tenían muchos errores y problemas de rendimiento.

El uso de la caché de código de operación de PHP le permite reducir el tiempo que el intérprete de PHP necesita para realizar la búsqueda, lectura y conversión de archivos a código de operación, que ejecuta directamente el intérprete de PHP.

El único punto que debe recordar es vaciar el caché del código de operación después de cambiar el código del servidor. Para hacer eso, simplemente reinicie el servidor web Apache (si usa mod_php) o el administrador Fast CGI. Otra variante es usar scripts específicos para administrar la condición de caché del código de operación. Para controlar APC, use el script apc.php del kit de distribución de APC. También se debe tener en cuenta que hay casos en los que la aplicación de caché de código de operación de PHP es inútil; entre estos se encuentran el uso de sphp, cgi o cli. ¿Por qué? La generación de caché de código de operación se ejecuta al inicio, pero en estos modos el intérprete finaliza la tarea después de que se procesa la consulta y se pierde el estado de caché.

caché Magento

Este tipo de caché de Magento contiene resultados de procesamiento de configuración (es decir, ensamblar archivos xml fragmentados en un solo archivo), ensamblar diseños, bloques HTML, etc. Este sistema de almacenamiento en caché permite evitar operaciones repetitivas con la condición de que no cambie nada que influya en estas partes del caché.

Recomendamos usar la memoria caché de Magento en todos los casos, excepto para proyectos de preparación o hosts de desarrolladores, de modo que evite la visualización irrelevante de la memoria caché durante la codificación.

Caché de página completa del lado de la aplicación

Este tipo de caché es diferente del caché de Magento porque contiene el código HTML de la página completa. Da aún más impulso para el procesamiento de consultas y muestra el resultado al usuario sin generar la página.

El uso de caché de página completa puede brindarle resultados impresionantes, alrededor de varias docenas de milisegundos por consulta. Es importante conocer la diferencia entre el tiempo de procesamiento de la consulta y el tiempo de carga de la página, ya que este último puede ser significativamente mayor y también depende del diseño de la página, el volumen de JS/CSS/imagen y otros archivos.

Este método es bueno para el almacenamiento en caché de páginas estáticas, pero puede tener dificultades con el contenido dinámico. Por ejemplo, la página del carrito de compras debe cambiar cuando se agregan, eliminan o modifican artículos. Además, a medida que el usuario navega por la tienda, el contenido del bloque «recientemente visto» debería cambiar. Si su solución de caché procesa estos casos incorrectamente, verá datos de página irrelevantes que, por supuesto, no son deseados.

Para solucionar esto, se diseñaron herramientas de caché con soporte de bloques dinámicos. Colocan un marcador especial en el código HTML de la página, que luego se reemplaza por el contenido del bloque dinámico relevante.

Por lo tanto, el caché de página completa del lado de la aplicación es perfecto en términos de relevancia de datos y equilibrio mínimo de carga del servidor.

Si ve que el caché de página completa es la solución que necesita para su tienda Magento, no dude en echar un vistazo a nuestra extensión Caché de página completa .

Caché de página completa del lado del servidor

Aquí está la diferencia con el FPC del lado de la aplicación: el FPC del lado del servidor almacena en caché el código HTML en el servidor, al que Magento pasa los resultados del procesamiento de la consulta. Siento que es importante señalar que, en este caso, el servidor tiene integración con Magento para rastrear la relevancia del caché y controlar los bloques dinámicos.

El tipo más famoso de esta familia es Varnish, que funciona con varios módulos de integración, por ejemplo, Nexcess Trementine. Si no hay actualizaciones de bloques dinámicos, Varnish procesa completamente la consulta, sin molestar a Magento. Por ejemplo, este esquema se usa para páginas CMS. Ahora, si la página contiene bloques dinámicos, entonces Varnish solicita a Magento que obtenga el contenido del bloque dinámico relevante, o el bloque será reemplazado con código AJAX, que solicitará el contenido necesario desde el lado del navegador.

Aquí, la velocidad de procesamiento de consultas depende del rendimiento del módulo de integración. En otras palabras, puede obtener mejores resultados con FPC del lado de la aplicación que con el del lado del servidor, si elige ciertos módulos de integración. Vea los resultados de la prueba Varnish on Nexcess Trementine aquí.

Por último, ¿Me va a ayudar Full Page Cache?

Aquí está el hecho que debe saber: FPC impulsa el proceso de generación de código HTML para la página que se solicita y para la que está habilitado el caché. En otras palabras, se reduce el ‘tiempo hasta el primer byte’.

Sin embargo, la memoria caché de página completa no puede impulsar el proceso de conexión del servidor, enviar una respuesta a una etapa del cliente y la carga de las fuentes de la página (JS, CSS, imágenes, fuentes) y, menos aún, cargar datos de servidores de terceros como Facebook, Google Plus, y Twitter. Estos últimos son a menudo una razón para el bajo rendimiento de las páginas. Por lo tanto, si decide colocar widgets o botones de redes sociales en su tienda Magento, tenga siempre en cuenta que también pueden influir en el rendimiento general del sitio.

Si desea ver la diferencia que FPC puede traer a su tienda, debe medir el «tiempo hasta el primer byte» para sus páginas. Use webpagetest.org para eso. Vaya a la herramienta, ingrese la URL de su página, elija la ubicación de prueba y elija la variante de conexión nativa (sin modelado de tráfico) para la opción de conexión. Si su sitio está protegido por autorización HTTP, vaya a la pestaña Auth y complete la información necesaria. Ahora, presione INICIAR PRUEBA. Debe tener un aspecto como este:

Una vez completada la prueba, verá la página de resultados:

Para obtener el número de ‘tiempo hasta el primer byte’, vaya a Waterfall for First View y busque la solicitud que funciona con la generación de código HTML de página. Para nuestro ejemplo, es la primera solicitud de la cascada. Puede ser diferente para su prueba, si tiene redireccionamientos de example.com → www.example.com o http://example.com → https://example.com.

Podemos ver que el tiempo de solicitud completo es de 135 milisegundos y el ‘tiempo hasta el primer byte’ es de 89 milisegundos. El tiempo de carga de la página completa es de 1.212 segundos. Supongamos que FPC da el resultado en 14 milisegundos, entonces el tiempo de procesamiento de la solicitud se reducirá en 75 milisegundos, pero el panorama general del tiempo de carga general de la página cambiará ligeramente; las mejoras rondarán el 7% de velocidad.

¿Por qué Amasty FPC no funciona con Varnish?

Hemos escuchado esta pregunta muchas veces. Bueno… Estas son las diferentes caras de la misma moneda. ¿Realmente necesitas ver cara y cruz al mismo tiempo? Oye, es casi imposible imaginar por qué necesitarías eso.

FPC y Varnish son dos herramientas diferentes que básicamente hacen lo mismo, por lo que debes elegir solo una y la decisión es tuya. Nuestra parte es diseñar una herramienta que ayude a su negocio y que esté hecha con cuidado y experiencia para brindar los mejores resultados.

Lo que estamos diciendo aquí: ni siquiera intentes usar Amasty FPC y Varnish en la misma instalación de Magento simultáneamente, ya que obtendrás más daños que beneficios. Lo mismo ocurre con el uso de varios tipos de FPC en la misma instalación de Magento simultáneamente: esta idea es tan mala como la anterior.

Ahora, eso es un final por hoy. Me encantaría responder a cualquier pregunta sobre el tema!