Caché de página completa en CE 1.8: ¿un módulo FPC Magento? ¿Barniz? ¿Ambos?

15

Así que estoy un poco confundido a medida que voy investigando el almacenamiento en caché de página completa para Community Edition 1.8. Ya he implementado una Redis Cache de dos niveles, CDN, sintonicé my.cnf de MySQL para un rendimiento máximo (con la base de datos en un servidor separado, por supuesto), y tengo 2 servidores que alojan nuestra tienda detrás de un equilibrador de carga. Digo eso para señalar que no estoy inmediatamente saltando para el FPC antes de hacer los ajustes iniciales de rendimiento.

Nunca he usado Varnish antes en ningún tipo de sitio, y mucho menos Magento, y tampoco he configurado un FPC en Magento. Entiendo que Varnish es un proxy que actúa como un cruce entre un CDN y un caché de página por sí mismo, enviando datos al navegador incluso antes de que la solicitud llegue al servidor web. Y a mi entender, un módulo FPC crea una memoria caché local que el servidor web en sí mismo distribuye. Sé que para ambas configuraciones, debe hacer un poco de "Perforación de agujeros" para llevar el contenido dinámico al navegador (aunque las técnicas son diferentes, entre usar un módulo o usar Barniz). Corrígeme si no estoy entendiendo nada aquí.

Hasta ahora, pensaba en ellos como dos entidades separadas que podría implementar para ayudar a su sitio, pero ahora algunas cosas que he leído parecen implicar lo contrario. Mi plan original era comprar el módulo " Warp Advanced Full Page Cache " para Magento (anteriormente, el "Tiny Brick Lightspeed FPC", creo), ya que parece ser el más popular, aunque sea un poco más caro (pero, francamente , $ 350 no es mucho para nuestra empresa, especialmente por lo que puede hacer). Yo y 2 de mis colegas desarrolladores estábamos planeando aprender a implementarlo de manera adecuada y completa dentro de nuestro propio tema personalizado y casero para maximizar lo que podemos obtener de él. Después de que se hizo eso, en algún momento en el camino, pensé que también buscaría implementar Varnish, pero, como dije antes, había entendido que estaban separados.

Ahora, sin embargo, estoy comenzando a encontrar extensiones como esta PageCache Powered by Varnish que es gratuita, o esta Vortex Cache Powered by Varnish Cache que cuesta casi $ 800 USD, que son módulos Magento Full Page Cache que funcionan directamente con Varnish.

Mi pregunta para usted, cambio de pila, es ¿cómo debería ver un FPC y Varnish? Como entidades separadas? Si es así, ¿son mutuamente excluyentes? ¿Son las dos caras de la misma moneda que debería implementar juntas? ¿O son similares pero no exclusivos ni inclusivos entre sí?

¿Puedo usar el Warp Advanced FPC que mencioné anteriormente con Varnish? ¿ Debo usarlo con barniz? ¿O sería mejor usar un FPC diferente si planeo usar Varnish? O aún más, ¿hay un FPC tan bueno que no necesito barniz? O viceversa, ¿debería usar Varnish y deshacerme de la idea de FPC?

Perdón por el muro de texto, pero he estado mirando muchos artículos, blogs y publicaciones en foros, y no he podido discernir una respuesta definitiva a esas preguntas. Realmente aprecio su ayuda y aporte en este asunto =)

Ah, y por último, una pregunta rápida sobre Varnish y servidores web. Actualmente estoy usando la configuración normal de la pila de Apache LAMP, pero desde hace un tiempo he visto a personas entusiasmadas con el uso de Nginx con Magento. He hecho algunas pruebas, pruebas de estrés y carga, y parece que definitivamente puede funcionar un poco mejor en las condiciones adecuadas. Como tal, estaba considerando cambiar en algún momento en el futuro cercano. ¿Esto afectaría de alguna manera mi deseo y decisión de usar un FPC y / o Barniz?

¡¡¡Gracias!!!

EDITAR: ¡Oh! Y una pregunta rápida más: dado que tengo dos servidores que alojan mi sitio detrás de un equilibrador de carga (que también es una configuración que se puede aumentar horizontalmente si fuera necesario), hago un uso completo de Redis y Memcached alojados en un servidor separado del Web y DB para mis sesiones y cada nivel de la caché de dos niveles de Magento (bueno, Zend). ¿Asumo que el FPC almacenaría sus datos en uno de esos sistemas? ¿Necesitaría tener una extensión específica para almacenarlo allí o todos lo hacen? Y aunque supongo que no, ¿afectaría esto a Varnish de todos modos? ¡¡Gracias de nuevo!!

ThatSourDiesel
fuente
Aparentemente solo puedo poner dos enlaces en mi muro de texto debido a mi falta de reputación. Qué manera de alentarme a ir a troll por puntos de Internet ... Dicho esto, aquí están los enlaces: Caché Vortex con Varnish Cache aa y PageCache con Varnish
ThatSourDiesel
3
No puedo ofrecer muchos consejos sobre Varnish, pero recomiendo echar un vistazo a Lesti FPC: gordonlesti.com/lestifpc Es completamente gratuito, tiene perforaciones, se puede configurar a través del administrador. Es absolutamente brillante
Paul
@ThatSourDiesel: ¿puede decirnos qué hizo? Preferiblemente bajo la respuesta aceptada, si usó eso para su solución al menos.
SPRBRN

Respuestas:

28

Hay dos cosas difíciles en informática:

  1. Nombrando cosas
  2. Invalidación de caché.

La perforación de agujeros cae en la categoría # 2 :)

General

El mejor enfoque es comenzar en los puntos más bajos de la pila y optimizar hasta la interfaz de Magento.


Base de datos y sistema de archivos

Siempre deben ser las primeras áreas en las que centrarse. Porque. E / S

MyTop es un útil script perl basado en Linux que imitará el comando 'top' de Linux y le dará una idea del estado de sus instancias de MySQL.

Htop es una parte superior más robusta . La función de strace puede ayudar a determinar las entradas y salidas de un proceso para encontrar posibles cuellos de botella.

Iotop es otra herramienta a considerar para monitorear E / S.

Otros útiles scripts de utilidad como mysqltuner.pl y mysql tunning primer pueden ofrecer información sobre las variables de tiempo de ejecución de MySQL y ofrecer consejos para ayudar. Tenga en cuenta que estos deben ser guías, ya que el mejor enfoque es siempre una evaluación de los requisitos y el ajuste basado en los datos conocidos recopilados. Hacerlo a ciegas puede causar más daño a veces que bien. Y ejecutarlos prematuramente sin al menos 24 horas de variables de tiempo de ejecución mysql puede ofrecer malos consejos.

Tenga en cuenta que Percona , MariaDB y MySQL estándar deberían funcionar con todo lo anterior. Favorece a Percona como una bifurcación MySQL, ya que Magento es tan pesado en InnoDB y XtraDB ofrece muchas herramientas y mejoras para el motor de base de datos.


Apache o Nginx

Todavía uso Apache, ya que ha servido a muchos otros, incluido yo mismo. También he usado y configurado Nginx. Si bien ofrece algunas ventajas, hay una curva de aprendizaje. Si bien las dos son opciones populares, ofrece algunas ventajas sobre Apache, una sería una huella de memoria más pequeña. Sin embargo, un Apache caído delgado que ejecuta PHP-FPM tendrá una huella de memoria similar.

Caso en punto:

Como este artículo trata sobre el rendimiento, debo señalar que una de las formas más fáciles de ayudar a apache a salir de su propio camino es no usar archivos .htaccess. Ponga lo que pondría allí en las estrofas de su Directorio, establezca AllowOverride en "None" y termine sin pedirle a Apache que recorra toda la ruta del documento para determinar si necesita prestar atención a .htaccess o no. Esta es una sugerencia básica y simple de ajuste que muchas personas parecen pasar por alto.

Para ayudar a facilitar esta salida:

El uso de un CDN para ayudar a aliviar cualquiera de las dos cosas obviamente ayudará, pero tendrá un beneficio adicional en la optimización de la interfaz ya que la mayoría de los navegadores de los usuarios finales podrán conectarse a ambos servidores con el mismo número de límites de conexión. Esto también libera a Apache de no tener que pasar por las verificaciones y solo para servir una imagen estática simple. Lighthttpd es una opción si desea ejecutar un servidor web estático solo para contenido además de un CDN.

PHP

PHP-FPM y APC. Úselos, elimine los módulos PHP innecesarios o no necesarios que no sean necesarios para Magento.


Código base de Magento

AOE_TemplateHints es excelente para determinar si sus bloques se almacenan en caché correctamente:

AOE_Profiler es bueno para la creación de perfiles, asegúrese de habilitar su creación de perfiles de capa de base de datos (obviamente en un entorno local / de desarrollo). Esto, junto con la herramienta mytop mencionada anteriormente, hace que encontrar SQL con mal comportamiento sea una tarea más fácil.

Módulos de terceros y código personalizado

Algunas buenas prácticas muy buenas para la optimización de Magento son una buena lectura, y tener en cuenta al revisar los módulos de terceros antes de usarlos. (hay muchos de mal comportamiento IMO).

Una herramienta Magniffer de Magento ECG ayudará a identificar fácilmente el código de mal comportamiento basado en el PDF proporcionado anteriormente. Sin embargo, se basa en Symfony / php-parser pero se puede instalar a través de Composer.


Barniz

uno no enciende el barniz

Como defensor de que Varnish fuera el autor era un desarrollador de kernel de FreeBSD, ofrece algunos tiempos de carga sub segundos secundarios. Sin embargo, si incluso tiene algunas de las más pequeñas diferencias en sus plantillas que no están listas para usar, pasará tiempo configurando barniz / magento para perforar el contenido que necesita. Lo más que he visto será simplemente AJAX'ify los elementos necesarios que no se almacenaron en caché de Varnish.

Hay varios módulos de Magento para ayudar a facilitar esta perforación y almacenamiento en caché:

En última instancia, esto debería estar en el último final de su viaje de optimización, y PUEDE requerir cierta personalización para hacer las cosas bien.


Magento CE FPC

Hasta ahora, el mejor CE FPC que he encontrado es: Lesti :: FPC

es un FPC de código abierto y gratuito para la comunidad muy bien elaborado (todo basado en observadores).


Al final del día, use sus propias pruebas y juicio.

Algunas lecturas adicionales:

B00MER
fuente
2

Sé un poco tarde para este hilo, pero si todavía está buscando una solución, es posible que desee considerar el almacenamiento en caché evolucionado . Es el mismo precio que Warp, pero:

  • Es muy rápido y fácil de instalar y configurar: todas las perforaciones y configuraciones se realizan desde el administrador
  • Se integra directamente con Varnish y le permite borrar y calentar su caché de Varnish desde Magento
  • Funciona con el frontend form_key introducido en 1.8 CE tanto en Varnish como en su propio caché.
  • Se desarrolla de forma muy activa con soporte receptivo. Nuevas versiones regulares con el objetivo de liberar correcciones de errores dentro de unos días después de informar
  • Tiene una extensa documentación que se actualiza con cada versión.

Configurar con Varnish es sencillo, solo necesita habilitar una configuración de administrador y usar el .vcl que se encuentra aquí . Tampoco está restringido a que Varnish solo sirva caché cuando no hay cookies como lo hace normalmente; obtiene una tasa de aciertos de caché muy alta.

Jonathan Hussey
fuente
Oh wow, interesante. Definitivamente lo investigaré. Debería publicar una actualización aquí. Básicamente, he decidido usar Varnish en lugar de un módulo de caché de página completa, pero me quedé atascado un poco sobre qué hacer con las partes dinámicas. ESI vs AJAX, en su mayor parte. Probé Varnish con Trementina, pero cuando tuve problemas para agregar cosas al carrito, lo saqué. Resulta que los problemas estaban relacionados con mi controlador de guardado de sesión de memcached, terminé encontrando más adelante. Entonces, dicho esto, todavía quiero recuperar Varnish, pero necesito pasar un tiempo asegurándome de que todas mis porciones dinámicas funcionen bien.
ThatSourDiesel
1
Seguro bueno. No creo que la trementina aún funcione con 1.8 CE debido a la inclusión de form_key en la interfaz; esto podría haber sido la razón por la que tuvo problemas para agregar al carrito. Personalmente, recomendaría Ajax sobre ESI principalmente porque ESI requiere que envíe una solicitud a Magento antes de que se entregue la página y esto siempre será lento. Quizás te interese ver esta publicación. fabrizio-branca.de/magento-varnish-ajax-vs-esi.html .
Jonathan Hussey
¡Me encanta el blog de Fabrizio! Definitivamente visto ese módulo AJAX suyo, a eso me refería cuando mencioné AJAX en ese último comentario mío. El problema de agregar al carrito que estaba teniendo se debió a algo extraño con memcached que logré solucionar, en realidad. Dicho esto, a pesar de que dicen que la trementina no funciona con 1.8 a menos que desactive la tecla form_key, me pareció que funcionaba bien. Sin embargo, no había entendido completamente ESI en ese momento, por lo que desde entonces se ha deshabilitado hasta que pueda pasar más tiempo implementando y probando. Perdí un poco de trabajo recientemente: me rompí la clavícula, tuve que someterme a una cirugía.
ThatSourDiesel
Por cierto, ¿el caché evolucionado es tu propio módulo? Solo por curiosidad, ¿estarías dispuesto a dejar que lo pruebe en mi servidor de ensayo? Podemos discutir en los nombres de dominio de PM y qué no para que pueda verificar que en realidad es un servidor de prueba y no producción =)
ThatSourDiesel
¡Espero que te estés recuperando después de tu cirugía! Sí, el módulo está desarrollado por mi empresa y sí, estamos muy contentos de permitirle probarlo en un dominio provisional / de desarrollo. Simplemente envíenos un correo electrónico utilizando la dirección de correo electrónico de servicio al cliente en la columna izquierda de nuestra tienda y lo recogeré: store.husseycoding.co.uk . Como nota al margen, contenta de que solucionado el problema memcached, vale la pena destacar que tal vez añadir a la cesta puede aparecer a trabajar bajo 1.8 para el usuario que hace que la página caché como su clave de formulario también se almacena en caché, pero borrar las cookies para obtener una nueva Clave de sesión + formulario y probablemente encontrará que falla.
Jonathan Hussey
1

Hemos escrito un FPC que es compatible con la nueva clave de formulario Magento 1.8. Caché de página completa de Brim: http://ecommerce.brimllc.com/full-page-cache-magento.html

BOOMER hace un gran punto sobre comenzar bajo en la pila y avanzar hacia arriba. Un FPC o Barniz debería ser lo último que hagas. Realizamos auditorías de rendimiento y comúnmente encontramos problemas con las configuraciones de MySQL y APC que están realmente apagadas. Al igual que los tamaños de búfer Innodb establecidos en el valor predeterminado y la base de datos ha crecido mucho más allá.

Recomendamos no usar ningún FPC con Barniz, a menos que esté específicamente diseñado para trabajar en conjunto. En general, no recomendamos Varnish a menos que tenga un puñado de servidores robustos que se hayan sintonizado junto con su base de código y aún tengan dificultades para mantenerse con el tráfico. Actualizar contenido dinámico puede ser complicado con Varnish específicamente cuando se trata de limitar sus solicitudes al backend de Magento y, a su vez, reducir la carga. Si tiene uno o dos cabezales web, las ganancias pueden no valer la pena el tiempo y la complicación.

En la mayoría de las situaciones, un buen FPC le proporcionará el rendimiento que necesita, por supuesto, después de que su servidor y su base de código se hayan ajustado. Con nuestro FPC puede obtener tiempos de generación inferiores a 15 ms en el caché de nivel 1 y sub 100 ms en el caché estándar. Nuestro caché de nivel 1 se usa para casos en los que el usuario no ha iniciado sesión y no tiene nada en su carrito, ya que no hace perforaciones. Cuando cualquiera de esas condiciones es falsa, el caché estándar se usa con soporte de perforación total.

Nuestro FPC tiene una perforación fácil incorporada y funciona con todos los bloques Magento estándar, así como cualquier bloque personalizado que pueda tener. Todo es configurable a través del panel de administración.

Recomiendo quedarse con Redis a menos que tenga problemas de escala con él. Tiene soporte de etiquetas y es mucho más rápido que memcached con archivos o bases de datos como backend lento. Si desea etiquetas y limpieza consistentes, debe usar memcached con base de datos cuando tiene varios cabezales web. Con el soporte de etiquetas de Redis incorporado, no tiene que preocuparse por eso. También puede usar Redis para sus sesiones.

Puedo hablar por todos los FPC, pero con los nuestros, puede configurar a través del administrador dónde almacenarlo. Puede elegir usar el backend de caché de Magento predeterminado o especificar configuraciones personalizadas para usar File, Database, APC, Redis, Memcache y un backend de archivo optimizado.

BrimSeth
fuente
Puede garantizar la entrega de menos de 20 ms al navegador. Solo Magento FPC lo he visto hecho en una tienda real en vivo.
Melvyn
0

No hay una respuesta correcta. Una tienda debe tener cargas de página dinámicas inferiores a 3 segundos e idealmente cargas de páginas dinámicas de 1 a 2 segundos, no es necesario menos de un segundo y es principalmente una estadística impulsada por el marketing. Apache es fácil de aprender y difícil de realizar, Nginx es difícil de aprender y fácil de realizar, muchos sitios se están mudando a Nginx, sin embargo, tener una arquitectura de alta calidad basada en Nginx y Magento no es simple.

Los clústeres Magento multiservidor ya son complejos de implementar, y aún más difíciles de mantener si no están en la arquitectura correcta, normalmente trabajamos con clústeres más grandes, lo que hace que todo funcione sin problemas, incluida la clasificación. Hacemos esto con la configuración de instalación estándar con cambios menores para la estabilidad a mediano y largo plazo, orientada a las cargas de página dinámicas de 1-2 segundos, lo que simplifica mucho el mantenimiento.

El barniz puede ser un FPC, CDN entre otros, sin embargo, en su caso, es mejor considerarlo como un FPC. Un FPC permite más visitantes en el servidor y proporciona una entrega estática más rápida, de la cual Varnish es una de esas herramientas, sin embargo, tiene varios problemas, incluido el contenido dinámico, el control de stock y los precios. La respuesta se reduce a cómo está estructurado su negocio, cómo se cargan sus datos, con qué frecuencia, su tipo de alojamiento y más, simplemente su negocio se ve afectado al proporcionar contenido estático a los visitantes. Técnicamente, puede mitigar gran parte de esto con la configuración de FPC, sin embargo, complica el entorno empresarial, desde la perspectiva del propietario del negocio, puede no producir un retorno equilibrado de la inversión.

El FPC es la última parte si tiene una carga dinámica inferior a 3 o mejor, su arquitectura puede manejar la amplitud de las solicitudes de los visitantes, ya que esto afecta la clasificación, absorbe los picos de marketing y vacaciones, y tiene el presupuesto para agregar complejidad en la arquitectura del servidor: el alojamiento debe ser 0.5 -1% de los ingresos para las empresas más pequeñas, la mayoría se ejecutan sustancialmente por debajo de este causando muchos problemas comerciales indirectos.

La razón por la que no ha encontrado una respuesta definitiva se debe al hecho de que esas preguntas tardan meses en responder ya que son cualitativas (basadas en el negocio) que requieren información que una empresa no querría publicar públicamente, las velocidades de carga de la página son cuantitativas (basadas en la técnica ) que puede publicarse, es la forma en que combina los dos lo que hace la solución.

VanquishTechnology
fuente
-2

Puede usar este caché de página de Magento que se adaptará a sus necesidades y es similar al barniz. Es utilizado por muchas de las tiendas Magento más grandes. Algunas caracteristicas:

  1. Al igual que Varnish, no utiliza una conexión de base de datos para el 90% de las solicitudes. Como resultado, es extremadamente rápido
  2. Tiene la capacidad de enjuagar automáticamente las páginas cuando cambian cosas como el inventario de productos y es muy bueno en eso
  3. Es un caché de varias capas, por lo que también admite perforaciones cuando los usuarios inician sesión (estas solicitudes requieren el uso de la base de datos)

Como caché multinivel, es escalable incluso para las tiendas de mayor tráfico y se ha utilizado en muchos sitios de tráfico extremadamente alto que reciben tráfico máximo, como las tiendas que se muestran en SharkTank (programa de televisión)

Extendware
fuente
Esto no responde a la pregunta del autor sobre si se debe usar barniz o FPC.
Steve Robbins
@extendware debe divulgar cuando es el autor de un producto. Agradecemos una valiosa contribución, pero no aceptamos el spam directo.
philwinkle