Precalentamiento de la caché de página completa de Magento Enterprise

Los beneficios de rendimiento del caché de página completa en Magento Enterprise son bastante conocidos. Lo que puede no ser tan conocido es que, para obtener el máximo beneficio de esto, debe estar completamente poblado y en caliente, particularmente en grandes conjuntos de productos en los que no tiene solo unas pocas páginas, haciendo uso del tráfico orgánico para imprima lo suficientemente rápido.

Magento incluye un cronjob incorporado para rastrear el sitio y calentar el FPC temprano en la mañana.

He visto y escuchado sobre problemas causados por trabajos de la madrugada que tardan demasiado en ejecutarse, bloqueando la ejecución de otros trabajos, y me gustaría saber qué usan otros o sugerirían que se usen para hacer esto. Un par de ideas que tengo son:

Arme un script de shell para rastrear cada página en el archivo de mapa del sitio generado.
Use una entrada de crontab separada y un script PHP corto para iniciar Magento y ejecutar el proceso del rastreador directamente.

Cualquier idea y / o experiencia sobre esto es bienvenida.

— davidalger
fuente

En realidad, puede llamar al rastreador Enterprise desde un archivo separado y usar el crontab de sus servidores para activarlo para que no se interponga.

— Toon Van Dooren

Puede usar el sitio en combinación con el sitemap.xmlarchivo, como lo hace MageSpeedTest .

#categories
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
#products
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1.0 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' >> urls.txt

Entonces corre

siege -i -c 1 -t 7200s -f urls.txt

^{Contenido procedente de aquí .}

— Ashley Schroder
fuente

También puede agregar un retraso entre las solicitudes usando–delay

— Ben Lessani - Sonassi

Nota: Estos comandos sed no funcionan en Darwin, pero sí en CentOS.

— davidalger

Esto no garantiza que cada URL sea "calentada". Siege seleccionará aleatoriamente las URL que se van a golpear desde el archivo, pero no necesariamente visitará todas las URL.

— Joe Constant

Simplemente no lo hacemos, en absoluto. Nunca. Diremos esto una y otra vez pero

Almacenamiento en caché! = Rendimiento

Su sitio debe ser rápido sin la adición de FPC (o Barniz para ese hecho). Siempre habrá un momento en que el contenido no esté preparado (su escenario anterior).

En una tienda descargada, los tiempos de carga de la página con FPC no deberían ser mucho más impresionantes que los que no son FPC; Magento es felizmente capaz de < 400mscargar tiempos de página en cachés estándar (en páginas de categoría / producto / búsqueda). FPC lo reducirá a < 80ms, pero viene con advertencias.

La información de stock / precio está desactualizada hasta la invalidación o el vencimiento de TTL
Los artículos nuevos / búsqueda más relevante no están actualizados hasta la invalidación o el vencimiento de TTL

etc.

Por qué confiar en FPC (o barniz) es una mala idea

Si está buscando asegurarse continuamente de que las memorias caché se ceben manualmente, es probable que haya algunas razones

No tiene suficientes pisadas naturales para mantener las cachés preparadas (consulte 'Dónde es útil el FPC')
Tu sitio es demasiado lento sin ellos

No puedes guardar todo en caché

Si toma una tienda con solo 5 categorías, 2 niveles anidados de profundidad, 5 atributos filtrables, 5 opciones de atributos cada uno y 1000 productos; Esas son muchas combinaciones posibles.

25 opciones para elegir, escogiendo una hasta 5 veces seguidas: no soy estadístico , pero sé que eso es ... (suponiendo que la cantidad de opciones de atributos no disminuya por completo)

25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5  possible URLs on the fifth selection

5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)

Ok, lo anterior no es un escenario probable, como me imagino, dentro de 3 clics: la cantidad de productos disponibles habría disminuido lo suficiente como para que el cliente encuentre su producto. Entonces, incluso si fuera ...

25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection

5^3 = 125 possible URL combinations

Luego multiplicado por 5 categorías, es decir 625 URL. En esta etapa, estamos hablando de un pequeño catálogo e ignorando por completo todas las URL del producto.

Tampoco tenemos en cuenta que si tuviera categorías anidadas con is_anchoron, aumentará exponencialmente.

Entonces, para rastrear ese volumen de páginas, debe esperar que los tiempos de carga de su página sean agradables y bajos, para que sea un proceso rápido y liviano (por lo tanto, anula el propósito del rastreo), o que tenga tiempo suficiente para que se complete antes de que caduque el TTL.

Si sus páginas tenían un tiempo de carga de la página de 0.4s y usted tenía una CPU de 8 núcleos, entonces ...

625 * 0.4 = 250 / 8 = 31 seconds

0,5 minutos, no está mal, pero imaginemos que tuvo tiempos de carga de página de 2 segundos

625 * 2 = 1250 / 8 = 156 seconds

Pero si tomaste el máximo escenario posible

3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes

Ese es su servidor de producción, con una carga de CPU del 100% durante 15 minutos. Reduciría la velocidad de rastreo proporcionalmente al TTL que desee.

Entonces, si desea que el contenido tenga un TTL de 3600, el rastreo podría ser 4 veces más lento, es decir. solo un 25% de CPU dedicada al rastreo. Eso es una gran cantidad de recursos solo para mantener el contenido de la categoría preparado: ni siquiera hemos tenido en cuenta los productos, los términos de búsqueda o las vistas adicionales de la tienda en esta etapa

De hecho, solo mirando el tamaño de las combinaciones en la catalog_url_rewritestabla (que ni siquiera tiene en cuenta los parámetros de la navegación en capas) dará una idea de cuántas URL podría terminar necesitando rastrear.

Ciertamente, cada tienda será diferente, pero lo que estoy tratando de recordar es que rastrear el sitio para preparar FPC no es práctico. Solo asegúrate de que tu tienda sea rápida para empezar .

Donde FPC es útil

Donde los beneficios de FPC entran en juego es en una tienda muy cargada, donde tienes niveles de tráfico genuinamente altos y los cachés están cebados de forma natural y continua solo por la simple caída del pie.

Luego, FPC entra en juego al reducir los gastos generales de infraestructura en el contenido comúnmente solicitado, reduciendo esas llamadas repetidas al backend de Magento.

Por lo tanto, descubrimos que FPC es excelente para implementar cuando tienes niveles de tráfico muy altos, no para reducir el tiempo de carga de la página, sino para reducir el uso de recursos.

A quién le importa, todavía quiero gatear

Bueno, entonces tienes dos opciones

Rastrear desde una plantilla (por ejemplo, mapa del sitio)
Extraiga enlaces página por página y rastree cada uno

Y hay muchas utilidades para hacer ambas cosas, estas son algunas que conozco

mage-perftest
HTTrack
Nutch
Sphider
Crawler4j

Usando Mage-Perftest

Puede rastrear su tienda con Mage-Perftest con bastante facilidad, primero descárguelo

wget http://sys.sonassi.com/mage-perftest          (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386     (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*

Luego defina el proceso de rastreo usando el mapa del sitio de Magento (puede personalizarlo haciendo un mapa del sitio de cualquier URL, siempre que las URL estén envueltas en <loc></loc>etiquetas). El siguiente comando leerá todas las URL del archivo de mapa del sitio, luego rastreará (solo PHP) las URL en el transcurso de 1440 minutos (1 día). Si el servidor supera el 20% de CPU o un promedio de carga de 2, el rastreo se detendrá temporalmente.

./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2

Si tiene 1000 URL, rastreadas durante 1 día, eso será aprox. 1 solicitud cada 86 segundo (s) ~ objetivo de 0.011 RPS

— Ben Lessani - Sonassi
fuente

Su línea de apertura es muy cierta ... el almacenamiento en caché de la página no es la forma de lograr el rendimiento. Yo se esto. No sabes cuántas veces le he dicho a los clientes lo mismo. Seré honesto, nunca he configurado un sitio donde tengamos un rastreador que cebe el FPC antes, y solo lo he visto usado una vez donde un cliente lo habilitó en el administrador ... ralentizando las cosas desde que etiquetan las etiquetas de caché. La razón principal por la que pregunto es porque estoy explorando ideas relacionadas con esto en base a algunas investigaciones en el documento técnico de Nexcess. Para sitios increíblemente de alto tráfico, cebar el caché después de enjuagarlo temprano en la mañana puede ser crítico

— davidalger

Respeto a Nexcess, pero su informe se centra mucho en el almacenamiento en caché para lograr el rendimiento, en lugar de garantizar que el entorno ya sea eficiente y que el código sea limpio, rápido y eficiente. Proporcionamos barniz para nuestros clientes, pero no recomendamos su uso hasta que sea necesario. Solo entonces como un medio para reducir los costos de infraestructura, es decir. cuando ~ 94% del tráfico sin conversión / finalización de la compra consume ciclos de CPU. El almacenamiento en caché ofrece buenas estadísticas de referencia artificial, pero en realidad no significa nada si los TTL son demasiado largos (contenido obsoleto) o si no hay suficiente tráfico para mantenerlo preparado.

— Ben Lessani - Sonassi

Para los sitios increíblemente de alto tráfico, tenemos algunos, y tratar de mantener caliente un caché a través del rastreo artificial no tiene sentido, el tráfico natural lo hace bien. En todo caso, el rastreo solo elimina recursos que de otro modo serían utilizados por los clientes.

— Ben Lessani - Sonassi

Les ruego que difieran en su documento técnico centrado en el uso del almacenamiento en caché para el rendimiento. Mostraban cuánto rendimiento podía lograr un clúster 2 + 1. Ni siquiera tocaron los tiempos de carga de la página, solo el rendimiento de la transacción. El hardware que tienen está tan optimizado como puede obtener ... y sí, me doy cuenta de los efectos de los TTL en el contenido en caché. Solo para repetir, no estoy buscando lograr un rendimiento aquí, ya lo tenemos. Lo que esto estaría explorando es formas de evitar retrasos / caídas en el rendimiento debido al vaciado de caché temprano en la mañana, es decir, antes de que el tráfico normal se recupere.

— davidalger

Estoy confundido entonces. Si su tienda ya es rápida, pero se cae cuando borra el caché. Ya sea a) No borre el caché por la mañana, hágalo la noche anterior y deje que los robots de rastreo de búsqueda (google / bing, etc.) se encarguen de usted o b) obtenga la infraestructura adecuada . Si su tienda depende de FPC / Barniz para evitar retrasos / desaceleración, entonces parece que está corriendo con el filo de un cuchillo ...

— Ben Lessani - Sonassi

Guardaré mi diatriba completa para una publicación de blog en estos días, pero mientras tanto tengo un pico en mi pequeño calentador de caché wfpc.

Prueba de rendimiento

Puede probar el rendimiento de su sitio Magento

./wfpc -t http://mymagentosite.com/sitemap.xml

Finished testing your Magento site performance
Total download time (in seconds)   : 5.0269110202789
Total download time (formatted)    : 0:0:5.026
Average page time (in milliseconds): 502.69110202789

Calentamiento FPC

Y puede calentar el FPC, que golpeará cada URL en sitemap.xml.

./wfpc -w http://mymagentosite.com/sitemap.xml

También puede poner un retraso entre las solicitudes si lo desea, aquí hay un retraso de 1 segundo entre las solicitudes.

./wfpc -w -d=1 http://mymagentosite.com/sitemap.xml

El modo de prueba solo alcanza 10 URL al azar, por lo que una vez que haya calentado su FPC, puede ejecutar el modo de prueba para descubrir qué diferencia hace el FPC.

Pensamientos

Personalmente, creo que un calentador tiene sentido ... En un sitio pequeño con aproximadamente 40 páginas, el tiempo de descarga se reduce aproximadamente a la mitad por el FPC. En un sitio grande con casi 40,000 productos que usan Lesti_FPC con APCu como back-end, estoy usando un poco más de 200MB para el caché, que francamente no es nada en el servidor de producción de 8GB.

— quickshiftin
fuente