php - Conseguir barniz para trabajar en Magento
caching cookies (7)
Primero, por favor, perdóname por la total falta de comprensión de Barniz. Este es mi primer intento de hacer algo con Varnish.
Estoy siguiendo el ejemplo en: http://www.kalenyuk.com.ua/magento-performance-optimization-with-varnish-cache-47.html
Sin embargo, cuando instalo y ejecuto esto, Varnish no parece tener caché. Obtengo el encabezado X-Varnish con un solo número y un encabezado Via que tiene un valor de 1.1 barniz
Me han dicho (por mi ISP) que es debido a la siguiente cookie que Magento configura:
Set-Cookie: frontend=6t2d2q73rv9s1kddu8ehh8hvl6; expires=Thu, 17-Feb-2011 14:29:19 GMT; path=/; domain=XX.X.XX.XX; httponly
Dijeron que tengo que cambiar Magento para manejar esto o configurar Varnish para manejar esto. Ya que cambiar Magento está fuera de discusión, me preguntaba si alguien podría darme una pista sobre cómo configurar Varnish para manejar esta cookie.
Cómo almacenar en caché Magento en Barniz (Teoría) - Hay 2 componentes para esto
1) Activos estáticos (por ejemplo, imágenes, CSS, JS): este es un patrón común y simple que involucra detectar solicitudes que pertenecen a esta categoría y establecer un tiempo de caché (o depender del tiempo de caché que envía el servidor de origen) Ejemplo de esto en forma esencial
2) Documentos HTML: esta es la parte mucho más compleja de una buena solución Magento. Es fundamental almacenar en caché documentos HTML en Varnish para poder mejorar el rendimiento de Magento. La generación de documentos HTML es la cosa más costosa (que consume mucho tiempo) que hará un servidor Magento.
El desafío con el almacenamiento en caché de documentos HTML proviene del contenido personalizado.
Contenidos personalizados y documentos HTML.
Magento, y todos los demás sitios de comercio electrónico, administran el estado de un usuario en particular a través de una sesión. Una sesión es un registro del estado de ese usuario en particular en su sitio. Esto cubre cosas tales como: "Hola Bob", en la parte superior de la página "4 Cosas en su carrito", el estado de su carrito de compras en cada página
Estos son elementos que no pueden compartirse entre los usuarios y podrían causar un problema importante si esto ocurriera (lo llamamos "fuga de sesión").
¿Cómo almacenamos en caché las páginas HTML si las páginas HTML contienen información personalizada sobre quién es la persona y qué contiene su carrito de compras?
Existen 2 métodos principales para lograr esto: Cargar elementos personalizados de la página a través de solicitudes adicionales después de que la página se haya cargado. Un método de implementación común aquí es utilizar AJAX para solicitar elementos de la página que se personalizan. Aprovechar una tecnología para marcar componentes del documento HTML como Se pueden almacenar en caché y no se pueden cachar (o no se pueden compartir entre usuarios). Varnish es compatible con una tecnología llamada ESI (Edge Side Include) que permite que diferentes partes de un documento HTML se almacenen en caché de manera diferente.
Su estrategia de implementación de Barniz debe tener en cuenta la personalización del usuario.
Opciones de implementación para Barniz
Magento 1.X: el método más utilizado para almacenar documentos HTML en la versión 1 de Magento es el producto de código abierto llamado Magento Turpentine (de Nexus). Este es un complemento que está instalado (a través de Magento Connect) y agregará automáticamente etiquetas ESI a sus documentos HTML para que Varnish pueda almacenar estos recursos en caché. Magento Turpentine instalacion / guia
Magento 2.X: la última versión de Magento (actualmente en versión beta) es compatible con Varnish como su solución recomendada para el almacenamiento en caché de HTML en producción. Esta es una gran noticia, Varnish es la opción recomendada de Magento y trabajará de manera inmediata para mejorar la velocidad de su sitio.
Cómo hacer que Varnish y Magento funcionen bien
La implementación es una cosa. Los próximos pasos, una vez que haya implementado y funcionando una solución Varnish Magento, es comprender qué tan bien está funcionando. Obtener métricas sobre las tasas de aciertos de caché y los registros detallados sobre una base de solicitud por solicitud puede ser un desafío, ya que implica la implementación de un rango de infraestructura adicional (o el bloqueo de la recopilación manual de registros de forma única).
Recientemente, hemos construido esta infraestructura para ejecutar Varnish como un servicio en la nube (con registros / métricas completas) - www.section.io - Conecte a un lado este puede ser el elemento más importante para el éxito real con su proyecto de Barniz y Magento según lo necesite. para ajustar constantemente su implementación para administrar cosas como cadenas de consulta variables en las URL (¡Hola, Google Analytics "gclid"!) que pueden reducir drásticamente las tasas de aciertos de caché
Creo que esto explica cómo podríamos usar barniz con magento.
Si usa el módulo aoe_static y mi vcl personalizado para el barniz 3, se borran las cookies en la respuesta de la página en caché. Debe hacer esto en vcl fetch. Las cookies se pueden configurar a partir de una respuesta ajax más pequeña que carga el contenido dinámico. Esto mantiene sus sesiones, carrito, etc. Esta respuesta ajax puede ser "canalizada" en vcl recovery.
No he experimentado ningún problema al hacer esto, pero no lo he probado en un sitio de producción.
Los bloques dinámicos deben reemplazarse con marcadores de posición a través de xml de diseño. Si le gustaron, estos reemplazos podrían incluir aplicaciones de borde de barniz o una implementación ajax personalizada.
Al cargar el contenido dinámico desde aoe_static (o cualquier otro tipo de métodos ajax que prefiera), es bueno recordar que aún puede usar el sistema de diseño magentos, por ejemplo, cree un identificador para su llamada ajax con bloques anidados para renderizar.
Si usa el módulo aoe_static, notará que se llama a loadLayout, pero recuerde que los identificadores se pasan a ese loadLayout. no es lo mismo que una solicitud de diseño para la página en la que está, pero tiene un identificador predeterminado para usted.
Otro problema son los niveles de stock. Cuando un producto ya no tiene un stock suficiente para agregar al carrito, seguirá apareciendo en las listas de productos y como opciones para productos configurables y agrupados.
Posiblemente podría usar el observador - cataloginventory_stock_item_save_after - para verificar los niveles de stock (no he comprobado esto). Luego, el caché se puede purgar en función de la url de los productos. Es bastante fácil obtener las urls de categoría en las que aparecería el producto y eliminarlas al mismo tiempo.
El módulo de Phoenix tiene métodos para hacer este tipo de purgas si desea ver una implementación fácil, simplemente siga los observadores.
Pero cómo tratar con las direcciones URL de navegación en capas es más complicado. necesitaría almacenar los parámetros de la cadena de consulta que la aplicación ha servido utilizando la url de la lista de categorías base como una clave por adelantado y luego leer y purgar estas urls en el observador. Este almacenamiento de los parámetros de la cadena de consulta sería bastante fácil utilizando la respuesta antes del envío, verificando el objeto de la solicitud con una expresión regular y registrando las cadenas de consulta usadas separadas por comas.
¿Me equivoco al pensar que ninguno de los módulos actuales se ocupa de los niveles de stock para la navegación por capas?
Creo que se necesita un buen módulo de barnizado en la comunidad de código abierto, ya que faltan todos los demás. personalmente planeo usar solo cachés pagados de página completa con servidores con carga equilibrada y tal vez barniz para capturar solicitudes de imágenes y css. A menos que alguien quiera unir fuerzas para realizar una implementación de barniz adecuada o me complacería ayudarle con los problemas de sus sitios si el trabajo se pudiera agregar a una implementación de código abierto que aborde mejor todas estas preocupaciones.
consulte esta pregunta para obtener más detalles sobre los problemas a los que se enfrentará esta pregunta: caché de página completa de código abierto de magento
Hemos desarrollado un módulo llamado PageCache impulsado por Varnish que permite que Magento y Varnish jueguen sin problemas al proporcionar un archivo de configuración de barniz (VCL) bien probado y un módulo de Magento bien integrado con muchas opciones para controlar la derecha del barniz desde el backend de Magento. Échale un vistazo a Magento Connect:
http://www.magentocommerce.com/magento-connect/Phoenix/extension/6322/varnish_cache
Si está utilizando Varnish 3.0, es posible que deba cambiar su configuración .vcl. Esto es lo que estoy usando con magento y barniz 3:
# This is a basic VCL configuration file for varnish. See the vcl(7)
# man page for details on VCL syntax and semantics.
#
# Default backend definition. Set this to point to your content
# server.
#
backend default {
.host = "127.0.0.1";
.port = "8080";
}
acl trusted {
"127.0.0.1";
"127.0.1.1";
# Add other ips that are allowed to purge cache
}
#
# http://www.varnish-cache.org/docs/2.1/tutorial/vcl.html#vcl-recv
# @param req Request object
sub vcl_recv {
if (req.http.x-forwarded-for) {
set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip;
}
else {
set req.http.X-Forwarded-For = client.ip;
}
if (req.request == "PURGE") {
# Allow requests from trusted IPs to purge the cache
if (!client.ip ~ trusted) {
error 405 "Not allowed.";
}
ban("req.url ~ " + req.url);
error 200 "Ok"; #We don''t go to backend
#return(lookup); # @see vcl_hit
}
if (req.request != "GET" &&
req.request != "HEAD" &&
req.request != "PUT" &&
req.request != "POST" &&
req.request != "TRACE" &&
req.request != "OPTIONS" &&
req.request != "DELETE") {
/* Non-RFC2616 or CONNECT which is weird. */
return (pipe);
}
# Cache only GET or HEAD requests
if (req.request != "GET" && req.request != "HEAD") {
/* We only deal with GET and HEAD by default */
return (pass);
}
# parse accept encoding rulesets to normalize
if (req.http.Accept-Encoding) {
if (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
# unkown algorithm
remove req.http.Accept-Encoding;
}
}
# Rules for static files
if (req.url ~ "/.(jpeg|jpg|png|gif|ico|swf|js|css|gz|rar|txt|bzip|pdf)(/?.*|)$") {
set req.http.staticmarker = "1";
unset req.http.Cookie;
return (lookup);
}
# Don''t cache pages for Magento Admin
# FIXME: change this rule if you use custom url in admin
if (req.url ~ "^/(index.php/)?admin") {
return(pass);
}
# Don''t cache checkout/customer pages, product compare
# if (req.url ~ "^/(index.php/)?(checkout|customer|catalog/product_compare|wishlist)") {
# return(pass);
# }
# Don''t cache checkout/customer pages, product compare
if (req.url ~ "/(checkout|customer|catalog/product_compare|wishlist)/") {
return(pass);
}
# Don''t cache till session end
if (req.http.cookie ~ "nocache_stable") {
return(pass);
}
# Unique identifier witch tell Varnish use cache or not
if (req.http.cookie ~ "nocache") {
return(pass);
}
# Remove cookie
unset req.http.Cookie;
set req.http.magicmarker = "1"; #Instruct varnish to remove cache headers received from backend
return(lookup);
}
sub vcl_pipe {
# # Note that only the first request to the backend will have
# # X-Forwarded-For set. If you use X-Forwarded-For and want to
# # have it set for all requests, make sure to have:
# # set req.http.connection = "close";
# # here. It is not set by default as it might break some broken web
# # applications, like IIS with NTLM authentication.
return (pipe);
}
#sub vcl_pass {
# return (pass);
#}
#sub vcl_hash {
# set req.hash += req.url;
# if (req.http.host) {
# set req.hash += req.http.host;
# } else {
# set req.hash += server.ip;
# }
# return (hash);
# }
# Called after a cache lookup if the req. document was found in the cache.
sub vcl_hit {
if (req.request == "PURGE") {
ban_url(req.url);
error 200 "Purged";
}
#
# ATTENTION!! I had to comment this to make it work on vernish 3.0!!!!
# error message:
# Symbol not found: ''obj.cacheable'' (expected type BOOL):
#
# I''m not sure about it, please check!!!
#
#if (!obj.cacheable) {
# return (pass);
#}
return (deliver);
}
# Called after a cache lookup and odc was not found in cache.
sub vcl_miss {
if (req.request == "PURGE"){
error 200 "Not in cache";
}
return (fetch);
}
# Called after document was retreived from backend
# @var req Request object.
# @var beresp Backend response (contains HTTP headers from backend)
sub vcl_fetch {
set req.grace = 30s;
# Current response should not be cached
if(beresp.http.Set-Cookie ~ "nocache=1") {
return (deliver);
}
# Flag set when we want to delete cache headers received from backend
if (req.http.magicmarker){
unset beresp.http.magicmarker;
unset beresp.http.Cache-Control;
unset beresp.http.Expires;
unset beresp.http.Pragma;
unset beresp.http.Cache;
unset beresp.http.Server;
unset beresp.http.Set-Cookie;
unset beresp.http.Age;
# default ttl for pages
set beresp.ttl = 1d;
}
if (req.http.staticmarker) {
set beresp.ttl = 30d; # static file cache expires in 30 days
unset beresp.http.staticmarker;
unset beresp.http.ETag; # Removes Etag in case we have multiple frontends
}
return (deliver);
}
# Called after a cached document is delivered to the client.
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT ("+obj.hits+")";
} else {
set resp.http.X-Cache = "MISS";
# set resp.http.X-Cache-Hash = obj.http.hash;
}
return (deliver);
}
#
# sub vcl_error {
# set obj.http.Content-Type = "text/html; charset=utf-8";
# synthetic {"
# <?xml version="1.0" encoding="utf-8"?>
# <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
# "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
# <html>
# <head>
# <title>"} obj.status " " obj.response {"</title>
# </head>
# <body>
# <h1>Error "} obj.status " " obj.response {"</h1>
# <p>"} obj.response {"</p>
# <h3>Guru Meditation:</h3>
# <p>XID: "} req.xid {"</p>
# <hr>
# <address>
# <a href="http://www.varnish-cache.org/">Varnish cache server</a>
# </address>
# </body>
# </html>
# "};
# return (deliver);
# }
Supongo que es una cookie de sesión que Magento envía a todos los usuarios: tuve un problema similar con Varnish + Redmine.
La razón por la que Varnish no está almacenando en caché sus páginas es porque, de forma predeterminada, solo almacena en caché lo que está seguro de que es seguro, y los usuarios con cookies normalmente ven cosas diferentes para una carga de página determinada, por ejemplo, si están conectados, tal vez su nombre de usuario esté en la parte superior de cada página, por lo que la página no se puede almacenar en caché †.
Sin embargo, muchos marcos proporcionan cookies de sesión a los usuarios que no han iniciado sesión también. Me temo que no conozco a Magento por lo que no puedo predecir las consecuencias de ignorar esta cookie: en Redmine, ignorar la cookie significaba que los usuarios no podían iniciar sesión y todos los formularios dejaron de funcionar (porque ya no tenían el CSRF). simbólico).
Probablemente sería mejor abordar esto desde el lado de Magento si puedes: Varnish escuchará los encabezados de la parte superior para determinar qué se puede almacenar en caché, etc.
Si no puede, entonces podría mitigarlo desde la configuración de Varnish. Querrá asegurarse de que el encabezado Set-Cookie no se envíe desde cualquier caché, y también querrá soltar la cookie del cliente en las solicitudes de páginas donde esa cookie no tiene efecto . Esto significa que necesitará excepciones para cosas como la pantalla de inicio de sesión, o cualquier página que requiera que usted inicie sesión (a menos que Magento establezca una cookie separada una vez que inicie sesión, lo que facilitaría mucho las cosas).
La documentación de Barniz (que puedo recomendar altamente como recurso) tiene varias páginas sobre el aumento de la tasa de aciertos, incluida una específica para eliminar cookies en algunas páginas y no en otras .
† Hay una excepción, que es si está utilizando las funciones de borde .
http://moprea.ro/2011/feb/16/magento-performance-optimization-varnish-cache-2/
No estoy seguro de si ayuda, pero me topé con esto.
De hecho, he intentado que el barniz funcione antes y he fallado. Le sugiero que obtenga APC + Memcached + tmpfs session / cache antes de probar el barniz.
http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/ describe la extensión de Magento que permite el caché de página completa con barniz. Esta extensión se basa en la configuración de Varnish publicada en github.
Estas son las características ya implementadas:
- Configuración de barniz trabajable
- Habilite el almacenamiento en caché de página completa utilizando Varnish, un proxy inverso HTTP de almacenamiento en caché súper rápido.
- Los servidores de barniz se pueden configurar en Admin, en Sistema / Configuración / General - Opciones de barniz
- Borra automáticamente (solo) páginas almacenadas en caché cuando se guardan productos, categorías y páginas CMS.
- Agrega un nuevo tipo de caché en Magento Admin, bajo Administración del sistema / caché y ofrece la posibilidad de desactivar el caché y actualizar el caché.
- Notifica a los usuarios del administrador cuando se guarda una navegación de categoría y se debe actualizar la caché de barniz para que el menú se actualice para todas las páginas.
- Desactiva el caché de barniz automáticamente para los usuarios que tienen productos en el carrito o que han iniciado sesión, etc.)
- Se ofrece la configuración de barniz predeterminada para que el módulo sea viable. Capturas de pantalla: https://github.com/madalinoprea/magneto-varnish/wiki