¿Varnish es adecuado para ti?
El barniz no es el máximo rendimiento del rendimiento de Magento. Es excelente para compensar la carga de bots y compradores de escaparates, pero no debería ser su primer puerto de escala para hacer que su tienda sea más rápida.
De hecho, implementar Varnish debería ser la última modificación de rendimiento en su tienda. Solo suéltelo una vez que vea los tiempos de carga de la página que Magento es capaz de entregar sin él (por ejemplo, <600 ms de tiempos de carga de la página).
Tu tienda aún necesita ser rápida
Como Varnish todavía requiere al menos una sola carga de página para cebar el caché, significa que su rendimiento no almacenado en caché aún debe ser muy bueno. La gran mayoría de las URL únicas (visitas de navegación en capas, consultas de búsqueda, etc.) nunca terminarán siendo publicadas desde Varnish a menos que:
a) Sus TTL son tan altos, que una consulta de búsqueda de hace 4 días todavía es válida hoy
b) La presencia en el sitio es tan amplia que las URL se rellenan en muy poco tiempo
También debe tener en cuenta que no todas las tiendas se prestan a Varnish . Cualquier sitio que aliente a los usuarios a crear una sesión personal (por ejemplo, iniciar sesión, agregar al carrito, etc.) al principio de su viaje con el cliente significará que Varnish será en última instancia redundante.
Por ejemplo, los sitios de compras privados fomentan el inicio de sesión de los usuarios desde el set, sin embargo, al hacer esto, significa que Varnish nunca tiene contenido no único que sea capaz de almacenar en caché. Por lo tanto, sus tasas de éxito serán drásticamente bajas y no habrá ningún beneficio al usar Varnish.
Contenido nuevo o tasas de éxito más altas
Imagen cortesía de magestack.com
El uso eficaz de Varnish se trata de lograr un equilibrio entre el contenido obsoleto y la cantidad de visitantes en su sitio.
Si tiene un sitio ocupado , lo más probable es que pueda salirse con TTL más bajos y todavía tener una alta tasa de éxito de barniz, y también continuar teniendo TTL bajos, por lo tanto, contenido más fresco. Por lo tanto, sus cambios de stock / precio se reflejan rápidamente y el caché se ceba continuamente del volumen de pisadas.
Si tiene un sitio de poco tráfico , entonces tendrá que comprometerse. Aumente sus TTL para garantizar una mayor tasa de aciertos o tenga contenido actualizado. No puedes tener ambas cosas. Sí, podría ejecutar una herramienta de rastreo / araña continuamente, pero los recursos que esto consumiría, y el gran volumen o las URL que se pueden rastrear (generalmente decenas de miles para pequeñas tiendas) significa que simplemente no es efectivo. Por lo general, las tiendas más pequeñas se beneficiarían más de una buena extensión FPC y de una configuración de servidor altamente optimizada.
Pero, por supuesto, puedo usar Varnish incluso cuando los usuarios inician sesión, ¿qué pasa con el caché por usuario o los ESI?
ESI
Los ESI son una excelente utilidad para poder mantener el contenido en la memoria caché y aún así poder tener bloques dinámicos en la página. Pero para usarlo de manera efectiva, debe minimizar la cantidad de devoluciones de llamada al mínimo. Hay un pequeño módulo de inicio que puede usar como base para este proceso, solo asegúrese de apretar los agujeros de seguridad, es muy inseguro por defecto, no hay restricciones sobre los controladores de diseño que puede / no puede cargar
Cada vez que se carga el bootstrap de Magento, tiene una penalización de rendimiento de alrededor de 200 ms, incluso antes de que cargue una colección / muestre un bloque, etc. Entonces, si tiene más de 3x ESI, es probable que haya terminado con tiempos de carga de página más lentos usando Varnish + ESI para contenido dinámico, que simplemente pasar por alto Varnish y pasar la solicitud directamente a Magento.
Por lo tanto, para utilizar realmente los ESI de manera efectiva, debe poder combinar varias solicitudes en una sola solicitud.
Por ejemplo, una página de vista de categoría que enumera 20 productos debe mostrar niveles de existencias precisos. Entonces usa ESI para cada bloque en la página. Eso sería 20x solicitudes de stock de ESI. Si bien las solicitudes de stock son muy livianas, ejecutar 20x de ellas simultáneamente afectaría el rendimiento. Por lo tanto, podría servir el bloque / colección completo de 20 productos y obtener esa solicitud 1x. Pero cargar y renderizar la colección es probablemente el elemento más lento de la página de todos modos, por lo que no ha ganado mucho.
El uso de ESI efectivamente necesita una planificación y ejecución adecuadas, o tendrá un sitio más lento que no usar Varnish en absoluto.
Caché por usuario
Luego está la alternativa de usar un caché específico del usuario. Esta es una mala idea a menos que tenga un sitio de muy poco tráfico. Su índice de visitas será terriblemente bajo, ya que las probabilidades de que un visitante llegue a la misma página en la que ya han estado son muy bajas. Y para cada cliente, esa página de 6Kb ocupará cada vez más espacio en su contenedor de almacenamiento de barniz.
Por ejemplo, si ha asignado 1 GB a Barniz. Con un sitio típico donde los usuarios ven 8 páginas por visita, en promedio 6 de esas páginas serán únicas. Eso es 28 visitantes por 1 MB de almacenamiento. Luego tenga en cuenta sus imágenes, CSS y JS: estas (afortunadamente) serán comunes, pero probablemente aún ocuparán entre 7 y 800 MB de su almacenamiento disponible. Esto te deja con 200 MB de almacenamiento restante, suficiente caché para 5.600 visitantes únicos.
Bueno, no me importa, solo quiero barniz
Bien, entonces deberás hacer lo siguiente:
- Instale un terminador SSL para sentarse antes de Varnish (por ejemplo, stud / pound / nginx)
- Instale Varnish en el servidor
- Asegúrese de configurar
X-Forwarded-Forcorrectamente
- Instale un módulo de barniz en su tienda
- Configure sus VCL Varnish para excluir extensiones de terceros
Como los primeros 3 puntos están más allá del alcance de esta respuesta, te lo dejaré a ti mismo. El punto 4 es un juego de niños y con el punto 5, continúe leyendo.
Lo más importante sobre la implementación de Varnish es garantizar que nunca almacene contenido en caché que nunca se debe almacenar en caché.
P.ej.
- Callbacks de pasarela de pago
- Resumen del carro
- Cliente mi resumen de cuenta
- Pagar (y llamadas respectivas de Ajax)
etc.
Para las URL principales de Magento, hay una lista bastante estándar de URI de las que puede escapar en Varnish:
admin|checkout|customer|catalog/product_compare|wishlist|paypal
Pero también debe considerar cualquier extensión personalizada / de terceros que también esté ejecutando y que tenga rutas, enrutadores y espacios de nombres personalizados. Desafortunadamente, no hay una manera fácil de saber qué URL de estas extensiones pueden y no pueden almacenarse en caché. Por lo tanto, debe evaluar cada uno caso por caso.
Como regla general, siempre que estemos configurando Varnish, comenzaremos identificando las rutas, enrutadores y espacios de nombres respectivos que puedan ocupar e ir desde allí. Hacemos esto a través de SSH:
grep -Eiroh "<frontName>.*</frontName>" community | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" community | grep "<from>"
grep -A5 -ir "<routers>" community
grep -Eiroh "<frontName>.*</frontName>" local | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" local | grep "<from>"
grep -A5 -ir "<routers>" local
Esto no le dará una lista definitiva de URL, pero seguramente le dará un comienzo.
No podemos enfatizar lo importante que es nunca almacenar en caché contenido que se supone que no debe almacenarse en caché. Los resultados podrían ser catastróficos.
En resumen
Al igual que con cualquier otra optimización de rendimiento del servidor Magento, implementada y ajustada correctamente puede realmente generar beneficios. Pero simplemente dejar caer el software sin configurarlo adecuadamente no solo hará que su tienda no sea más rápida, sino potencialmente más lenta, más insegura y menos confiable.
