Caché de página completa en CE 1.8 - ¿Un módulo FPC Magento? ¿Barniz? ¿Ambas cosas?
https://magento.stackexchange.com/questions/13957
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Así que estoy un poco confundido mientras investigo el almacenamiento en caché de la página completa para Community Edition 1.8. Ya he implementado un Redis Cache de dos niveles, CDN, ajusté MySQL My.cnf para el rendimiento máximo (con el DB en un servidor separado, por supuesto), y tengo 2 servidores que alojan nuestra tienda detrás de un equilibrador de carga. Digo que para señalar que no estoy saltando de inmediato para el FPC antes de hacer los ajustes de rendimiento iniciales.
Nunca he usado barniz antes en ningún tipo de sitio, y mucho menos Magento, y tampoco he configurado un FPC en Magento. Entiendo que el barniz 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 antes de que la solicitud llegue al servidor web. Y a mi punto de tener en cuenta, un módulo FPC crea un caché localmente que el propio servidor web repara. Sé que para ambas configuraciones, debe hacer un "golpe de hoyo" para llevar el contenido dinámico al navegador (aunque las técnicas son diferentes, entre usar un módulo o usar barniz). Por favor, corrígeme si estoy malinterpretando algo aquí.
Hasta justo ahora, pensé en ellas como dos entidades separadas que podrías implementarlo ayuda a su sitio, pero ahora algunas cosas que he leído parecen implicar lo contrario. Mi plan original era comprar el "Warp Advanced Cache de página completa"Módulo para Magento (anteriormente el" Tiny Brick Lightspeed FPC ", creo), ya que parece ser el más popular, si es un toque más caro (pero, francamente, $ 350 no es mucho para nuestra compañía, especialmente para lo que puede hacer). Yo y 2 de mis compañeros desarrolladores planeamos aprender a implementarlo adecuadamente y completamente dentro de nuestro propio tema casero personalizado para maximizar lo que podemos sacar de él. Después de eso, en algún momento en algún momento del Road, pensé que también buscaría implementar barniz, pero, como dije antes, había entendido que estaban separados.
Ahora, sin embargo, estoy empezando a encontrar extensiones como esta pageCache alimentada por barniz que es gratuita, o este caché de vórtice alimentado por caché de barniz, que es de casi $ 800 USD, que son módulos de caché de página completa magento que funcionan directamente con barniz.
Mi pregunta para ti, Stack Exchange, ¿cómo debo ver un FPC y un barniz? Como entidades separadas? Si es así, ¿son mutuamente excluyentes? ¿Son dos lados de la misma moneda que debería implementar juntos? ¿O son similares pero no exclusivos ni inclusivos el uno al otro?
¿Puedo usar el FPC avanzado Warp que mencioné anteriormente con barniz? Debería Lo uso con barniz? ¿O sería mejor usar un FPC diferente si planeo usar barniz? O incluso más, ¿hay un FPC tan bueno que no necesito barniz? O viceversa, ¿debo usar barniz y deshacerme de la idea de FPC?
Perdón por el muro del texto, pero he estado buscando muchos artículos, blogs y publicaciones del foro, y no he podido discernir una respuesta definitiva a esas preguntas. Realmente aprecio su ayuda y su opinión en este asunto =)
Ah, y por último, una pregunta rápida sobre el barniz y los servidores web. Actualmente estoy usando la configuración normal de la pila de la lámpara Apache, pero durante un tiempo he estado viendo a la gente delirante de usar NGINX con Magento. He realizado algunas pruebas yo mismo, estrés y pruebas de carga, y parece que definitivamente puede funcionar un poco mejor en las condiciones correctas. Como tal, estaba considerando cambiar en algún momento en el futuro cercano. ¿Esto afectaría de todos modos mi deseo y decisión de usar un FPC y/o barniz?
¡¡¡Gracias!!!
Editar: ¡Oh! Y una pregunta más rápida: 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 la necesidad surge), hago uso completo de Redis y Memcached alojado en un servidor separado del Web y DB para mis sesiones y cada nivel de caché de dos niveles de Magento (bueno, Zend). Supongo que el FPC almacenaría sus datos en uno de esos a sistemas. ¿Necesitaría tener una extensión específica para almacenarla allí o todos lo hacen? Y aunque supongo que no, ¿afectaría esto a los barniz de todos modos? ¡¡Gracias de nuevo!!
Solución
Hay dos cosas difíciles en informática:
- Nombrar cosas
- Invalidación de caché.
El 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 el interfaz de Magento.
Base de datos y sistema de archivos
Siempre deben ser las primeras áreas en las que se concentrará. Porque. I/O.
Mi top es un práctico script de Perl basado en Linux que imitará el comando 'superior' de Linux y le dará una idea del estado de sus instancias (s) MySQL.
Htop es un Top más robusto, Los santa La característica puede ayudar a determinar los informes/outs de un proceso para encontrar posibles cuellos de botella.
IOTOP es otra herramienta a considerar para monitorear la E/S.
Otros útiles scripts de utilidad como mysqltuner.pl y MySQL Tunning Primer Puede ofrecer información sobre sus variables de tiempo de ejecución MySQL y ofrecer consejos para ayudar. Tenga en cuenta que estas están destinadas a ser guías, ya que el mejor enfoque es siempre una evaluación de los requisitos y la afinación basada en datos conocidos recopilados. Hacerlo ciegamente 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 de MySQL puede ofrecer malos consejos.
Tenga en cuenta Percona, Mariadb y Standard MySQL deberían funcionar con todo lo anterior. Favorecer a Percona como una bifurcación MySQL, ya que Magento es tan pesado en Innodb y XTRADB ofrece muchas herramientas y mejoras al motor DB.
Apache o nginx
Sigue usando Apache, ya que ha servido bien a muchos otros, incluido yo mismo. He usado y configurado NGINX también. Si bien ofrece algunas ventajas, hay una curva de aprendizaje. Si bien los dos son opciones populares, ofrece algunas ventajas sobre Apache, una sería una huella de memoria más pequeña. Sin embargo, un Apache delgado y caído que ejecuta PHP-FPM tendrá una huella de memoria similar.
Caso en punto:
Dado que este artículo era 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. Coloque lo que pondrías allí en las estrofas de tu directorio, establezca el TermetMoverride en "Ninguno" y termina sin pedirle a Apache que atraviese toda la ruta del documento para determinar si necesita prestar atención a .htaccess o no. Esta es una pista básica y simple de sintonía que muchas personas parecen perderse.
Para ayudar a facilitar este consulta:
Utilizar un CDN para ayudar a eliminar la facilidad de cualquiera de los dos ayudará, pero habrá agregado beneficio en la optimización de frontend, ya que la mayoría de los navegadores de usuarios finales podrán conectarse a ambos servidores con la misma cantidad de límites de conexión. Esto también libera a Apache de no tener que saltar a través de cheques y tal 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 requeridos que no se necesiten para Magento.
Base de código Magento
Aoe_templatehints es genial para determinar si sus bloques están almacenando en caché correctamente:
- https://github.com/fbrnc/aoe_templatehints
- http://www.fabrizio-branca.de/magento-Advanced-Template-Tints-20.html
Aoe_profiler es bueno para el perfil, asegúrese y habilite su perfil de capa DB (obviamente en un entorno local/de desarrollo). Esto junto con el mi top La herramienta mencionada anteriormente hace que la búsqueda de SQL de comportamiento malo sea una tarea más fácil.
Módulos de terceros y código personalizado
Algunas muy buenas prácticas mejores para la optimización del propio Magento son una buena lectura, y tener en cuenta al revisar los módulos de terceros antes de usarlos. (Hay muchos malos comportamientos en mi opinión).
Una herramienta magniffer de Magento ECG ayudará a identificar fácilmente un código de comportamiento malo basado en el PDF proporcionado anteriormente. Sin embargo, se basa en Symfony/PHP-Parser pero es instalable a través del compositor.
Barniz
Como un defensor de que Barnish era el autor era un desarrollo de kernel de FreeBSD, ofrece algunos tiempos de carga de subcubras locos. Sin embargo, si incluso tiene algunas de las más mínimas diferencias en sus plantillas que no están fuera de caja, pasará tiempo configurando barniz / magento para holear el contenido que necesita. La mayoría de los que he visto simplemente AJAX 'los elementos necesarios no se colocan en el barniz.
Hay una serie de módulos Magento para ayudar a facilitar el golpe y el almacenamiento en caché de este agujero:
- Aoe_static: https://github.com/aoemedia/aoe_static
- Nexcess Turpentina: https://github.com/nexcess/magento-turpentine
En última instancia, esto debería ser en el último extremo de su viaje de optimización, y MAYO requiere cierta personalización para acertar las cosas.
Magento ce fpc
Hasta ahora el mejor CE FPC que he encontrado es: Lesti :: FPC
Es un FPC de código abierto muy bien organizado (todos basado en observadores) y FPC gratuito para la comunidad.
- http://gordonlesti.com/lestifpc/
- https://github.com/gordonlesti/lesti_fpc (Github en caso de Link Future Dead)
Al final del día Use sus propias pruebas y juicio.
Algunas lecturas adicionales:
Otros consejos
Un poco tarde a este hilo lo sé, pero si todavía está buscando una solución, es posible que desee considerar, Almacenamiento en caché evolucionado. Es el mismo precio que Warp, pero:
- Es muy rápido y fácil de instalar y configurar: todos los puñetazos y configuración de hoyos se realizan desde admin
- Se integra directamente con el barniz y le permite despejar y calentar su caché de barniz desde Magento
- Funciona con el frontend Form_key introducido en 1.8 CE tanto en barniz como en su propio caché.
- Se desarrolla muy activamente con apoyo receptivo. Nuevas versiones regulares con el objetivo de publicar correcciones de errores dentro de unos días posteriores a la presentación de informes
- Tiene extenso documentación que se actualiza con cada versión
Configurar con barniz es sencillo, solo necesita habilitar una configuración de administrador y usar el .vcl encontrado aquí. Tampoco está restringido a barniz solo para servir caché cuando no hay cookies presentes según lo normal: obtiene una tasa de golpe de caché muy alta.
Hemos escrito un FPC que es compatible con la tecla de formulario Magento 1.8. El caché de la página completa de Brim: http://ecommerce.brimllc.com/full-page-cache-magento.html
Boomer hace un gran punto sobre comenzar a la pila y avanzar. Un FPC o un barniz debe ser lo último que lo hace. Hacemos auditorías de rendimiento y comúnmente encontramos problemas con las configuraciones de MySQL y APC que están realmente desactivadas. 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á de él.
Recomendamos que no use cualquier FPC con barniz, a menos que se diseñen específicamente para trabajar juntos. En general, no recomendamos barniz a menos que tenga un puñado de servidores robustos que se hayan sintonizado junto con su base de código y aún luchen por mantener el tráfico. Actualizar el contenido dinámico puede ser complicado con el barniz específicamente cuando intenta limitar sus solicitudes al backend de Magento y, a su vez, reduciendo la carga. Si tiene uno o dos cabezas web, las ganancias pueden no valer el tiempo y la complicación.
En la mayoría de las situaciones, un buen FPC le dará el rendimiento que necesita, por supuesto, después de que su servidor y la base de código se hayan sintonizado. Con nuestro FPC puede obtener los tiempos de generación de menos de 15 ms en el caché de nivel 1 y los sub 100 ms en el caché estándar. Nuestro caché de nivel 1 se usa para los casos en que el usuario no se registra y no tiene nada en su carrito, ya que no hace golpes de agujeros. Cuando cualquiera de esas condiciones es falsa, el caché estándar se usa con soporte de perforación de orificio completo.
Nuestro FPC tiene un puñetazo fácil y funciona fuera de la caja con todos los bloques Magento estándar, así como cualquier bloques personalizados que pueda tener. Todo es configurable a través del panel de administración.
Recomiendo seguir con Redis a menos que tenga problemas de escala con él. Tiene soporte de etiqueta y es mucho más rápido que Memcached con archivo o base de datos como backend lento. Si desea etiquetas y limpieza consistentes, debe usar Memcached con una base de datos cuando tiene varios cabezales web. Con el soporte de etiqueta de Redis integrado, no tiene que preocuparse por ello. También puede usar Redis para sus sesiones.
Puedo hablar por todos los FPC, pero con el nuestro, puede configurar a través del administrador dónde almacenarlo. Puede optar por usar el backend de caché magento predeterminado o especificar la configuración personalizada para usar el archivo, la base de datos, APC, Redis, Memcache y un backend de archivo optimizado.
No hay una respuesta correcta. Una tienda debe tener cargas de página dinámicas Sub 3S e idealmente cargas de página dinámicas de 1-2S, Sub-Second no es necesario y es principalmente una estadística impulsada por el marketing. Apache es fácil de aprender y difícil de hacer, NGINX es difícil de aprender y fácil de hacer, muchos sitios se mueven a Nginx, sin embargo, tener una arquitectura de alta calidad basada en Nginx y Magento no es simple.
Los grupos Magento de múltiples servidores ya son complejos de implementar, y aún más difíciles de mantener, si no en la arquitectura correcta, normalmente trabajamos con clústeres más grandes, lo que hace que todo funcione más suavemente, incluida la clasificación. Hacemos esto con la configuración de instalación estándar con cambios menores para la estabilidad de mediano a largo plazo dirigido a las cargas de página dinámica 1-2S, hace que todo sea mucho más simple para el mantenimiento.
El barniz puede ser un FPC, CDN, entre otros, sin embargo, en su caso es mejor pensar que es un FPC. Un FPC permite más visitantes en el servidor y proporciona una entrega estática más rápida de la cual el barniz es una de esas herramientas, sin embargo, hay varios problemas con él, incluido el contenido dinámico, el control de existencias, los precios. La respuesta se reduce a cómo se estructura su negocio, cómo se cargan sus datos, con qué frecuencia, su tipo de alojamiento y más, simplemente se ve afectado su negocio 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 de un negocio, puede que no produzca un retorno equilibrado de la inversión.
El FPC es la última parte si tiene sub 3s o una mejor carga dinámica, su arquitectura puede manejar el valor en las solicitudes de los visitantes, ya que esto afecta la clasificación, absorberá marketing y picos de vacaciones, y tiene el presupuesto para agregar complejidad en la arquitectura del servidor; el alojamiento debe ser 0.5 -1% de los ingresos para empresas más pequeñas, la mayoría se ejecutan sustancialmente bajo esto, lo que causa 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 negocios) 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 técnicas (basadas en técnicas. ) que se puede publicar publicidad, es cómo combina los dos lo que hace la solución.
Puedes usar esto Caché de la página de magento que se ajustará a sus necesidades y es similar al barniz. Es utilizado por muchas de las tiendas Magento más grandes. Algunas caracteristicas:
- Al igual que el barniz, no utiliza una conexión de base de datos para el 90% de las solicitudes. Como resultado, es extremadamente rápido
- Tiene la capacidad de las páginas automáticas cuando cambian cosas como el inventario de productos y es muy bueno en eso
- Es un caché de múltiples capas, por lo que también es compatible con el perforación de agujeros cuando los usuarios inician sesión (estas solicitudes requieren uso de la base de datos)
Como caché de varios niveles, es escalable incluso para las tiendas de tránsito más altas y se ha utilizado en muchos sitios de tráfico extremadamente alto que reciben tráfico pico, como tiendas que aparecen en SharkTank (programa de televisión)
