Estudio de estudio de rendimiento de alojamiento de Magento

Comenzamos en esta misión a descubrir cómo los sitios magento funcionan en la naturaleza. Noté que muchos sitios de Magento ofrecen una experiencia lenta para el usuario final y que los problemas de rendimiento a menudo se buscan con diferentes métodos de caché. ¿Es toda la página almacenado en caché una forma viable de resolver problemas de rendimiento de Magento? ¿El reemplazo de backend de caché mejorará el rendimiento de Magento? ¿Hay otras mejores formas de resolver los problemas de rendimiento del host Magento? Tiempo de respuesta de Magento, latencia del servidor y tiempo para el primer tiempo de respuesta del sitio web de bytes Cuenta para visitantes del sitio, clientes y conversión y se llama popularmente a First Byte. A diferencia de lo que la mayoría cree, el almacenamiento en caché no es lo que determina el rendimiento de su sitio web, o al menos no como espere.
El tiempo para el primer byte (TTFB), o la latencia del servidor, es el nombre del retraso que comienza al hacer clic en una página web y hasta que se reciba el primer byte a través de la red. Un TTFB bajo le da al visitante del sitio la sensación de entrega instantánea de una página web al hacer clic en algo. Esta prueba se centra en TTFB, y los resultados no dicen nada sobre escalabilidad y capacidad máxima o el rendimiento frontal de los sitios probados. Sin embargo, un alto TTFB nos dice, como profesionales en el alojamiento, que la escala del sitio será mucho más difícil, y que el rendimiento y la experiencia para el usuario final son malos.
Una cosa común para todas las tiendas que he probado es que tienen bastante tráfico. Por lo tanto, esperaríamos que los sitios se configuren correctamente y funcionen bien cuando se pruebe para su rendimiento. El objetivo de la prueba de rendimiento de Magento, el objetivo principal de la prueba es recopilar los tiempos de respuesta, la distribución de los tiempos de respuesta e información sobre qué tan bien funciona todo el almacenamiento de la página. Los resultados proporcionarán una perspectiva interesante sobre la experiencia del usuario para los visitantes de la tienda. Probamos el rendimiento de 15 sitios populares de comercio electrónico de Magento, organizados por diferentes compañías en diferentes lugares en el norte de Europa. El siguiente gráfico es un ejemplo que muestra la distribución de los tiempos de respuesta como quisieran (karitraa.com). La mayoría de las solicitudes en la prueba inicial se entregan en menos de 1 segundo, y algunas solicitudes en 2 segundos. La prueba de caché consecutiva muestra que el almacenamiento de toda la página funciona para casi todas las solicitudes, lo que nos dice que el alto tráfico habría tratado sin problemas.
Comportamiento no deseado El siguiente gráfico es un ejemplo de una prueba equivalente como se indicó anteriormente (Hoyer.no), pero con resultados que nos dicen que los usuarios tienen una experiencia muy mala. Solo se atiende un pequeño porcentaje de solicitudes en menos de 1 segundo, y la gran mayoría se atiende en tres segundos o más.

La distribución en la prueba de caché también sugiere que el almacenamiento de caché de toda la página está en uso, pero para la gran mayoría de las solicitudes, no funciona. El alto tráfico de repente a este sitio probablemente lo haría que no esté disponible, porque los recursos de backend se gastarían para la entrega, la mayoría de los problemas. La presentación general de los resultados que medí el tiempo que debe esperar antes de que el navegador comience a reconstruir el página web. Este es el momento en que todos tienen que esperar antes de que otras optimizaciones entren en juego. No importa cómo el front-end sean imágenes optimizadas-pequeñas, agregación CSS y JavaScript, reduciendo las búsquedas de nombres de dominio: este tiempo de espera se aplica a todos.
La experiencia del usuario es lo que importa para la conversión y utilizamos los siguientes valores de referencia cuando medimos y evaluamos el tiempo al primer byte:

El tiempo de respuesta promedio menos de 0.8 segundos generalmente proporciona un buen rendimiento
El tiempo de respuesta promedio durante 0.8 segundos le da a las tiendas una sensación algo lenta
El tiempo de respuesta promedio durante 1.2 segundos es lento y se arriesga a que las personas comiencen a hacer doble clic
El tiempo de respuesta promedio durante 1.5 segundos sugiere visitantes molestos y luchadores
Más de 2 segundos garantizan una mala experiencia del usuario
Cómo leer y analizar este gráfico
Las barras de tiempo de respuesta roja muestran el tiempo de respuesta que la mayoría de los visitantes experimentarán


Solo los primeros cuatro sitios tienen tiempos de respuesta promedio aceptables y consistentes por debajo de 0.8 segundos
Las barras azules del tiempo de respuesta pueden ocurrir para los visitantes durante eventos de tráfico intensos, alcanzando el caché de la respuesta de respuesta completa de menos de un segundo para las pruebas de caché de página completa indican el uso efectivo del almacenamiento en caché de la página completa (los tiempos de respuesta de prueba FPC menos de 0.5 No se deben comparar segundos porque la latencia de la red es la principal fuente de variación)
Las grandes diferencias absolutas entre la ejecución inicial y la confirmación sugieren que el rendimiento varía al azar (Helllyhansen.com, Eplehuset.no, Thyer.no)
Alguna información adicional sobre los tres sitios web alojados por ServBolt: YMeuniverse.com, CoverBrands.no y Karitraa.com
Ninguno de estos usa redis u otras troncos de caché alternativos
CoverBrands.NO ofrece el segundo mejor tiempo de respuesta y no utiliza todo el almacenamiento de la página. Se ha demostrado que se extiende a más de 2000 usuarios simultáneamente sin una configuración de clúster
Karitraa.com funciona con PHP 5.6. La actualización del sitio a PHP 7 reduciría otro 35-50% del tiempo de respuesta promedio
Enklereliv.No es el único sitio sin servicio que ofrece un gran rendimiento en esta prueba. Nuestros números al aire libre y la inspección de la configuración sugieren que el caché de toda la página se activa en cualquier momento.
La posibilidad de bajo rendimiento El siguiente gráfico incluye todos los sitios que respondieron en promedio más del 3.5% de las páginas en más de 2 segundos. Los visitantes del sitio generalmente visitan más de una página, pero este gráfico muestra la oportunidad de acceder a una página+de 2 segundos+.
Los resultados del almacenamiento de caché de toda la página Estos diagramas incluyen solo los sitios que implementan efectivamente el caché de la página de escala completa. Las barras azules muestran el rendimiento general. CoverBrands.No no usa el caché de toda la página, pero se incluye para enfatizar que es posible lograr actuaciones notables, sin usar el caché de toda la página.
Hubo varios sitios que han implementado el caché de toda la página, pero si la cantidad de solicitudes atendidas en caché era demasiado pequeña para que fuera efectiva para la escala, estos sitios no figuran en la lista. Helly Hansen y Stormberg tienen un rendimiento lento, pero se escalarán con el tráfico. Fjellsport.no generalmente es lento, y voorwinden.nl y ePlehuset. No generalmente ofrece una mala experiencia del usuario, a menos que los visitantes tengan suerte y accedan a una página de caché.
El puntaje de rendimiento hice un índice que refleja el rendimiento de TTFB en el que se esperan los visitantes, ofreciendo resultados en una escala de 0 y 100, donde 100 es el mejor puntaje posible. El índice consta de los siguientes elementos;

Tiempo de respuesta (hasta 30 puntos)

Tiempo de respuesta en caché (hasta 20 puntos)
Oportunidad de llegar a la página <1S (hasta 30 puntos)

Oportunidad de llegar a la página <2s (hasta 20 puntos)
Bauhaus.se
Sitio: Bauhaus.se
Desarrollador: Vaimo
Organizado en: Bauhaus it
Plataforma: Magento Commerce
Usando caché de la página completa: no
Ranking de Alexa: 46467
EPlehuset.nr
Sitio: ePlehuset.no
Desarrollador: Convertir
Organizado en: Amazon



Plataforma: Magento Commerce
Usando el caché de la página completa: sí
Ranking de Alexa: 184868hellyhansen.com
Sitio: Hellyhansen.com
Desarrollador: Vaimo
Organizado en: Amazon
Plataforma: Magento Commerce



Usando el caché de la página completa: sí
Ranking de Alexa: 47695
Gsport.nr
Sitio: GSPORT.NO
Desarrollador: Ate
Organizado en: Embriq
Plataforma: Magento Commerce



Usando el caché de la página completa: sí
Ranking de Alexa: 72478
Bobina de cobertura.nr
Sitio: coberturas. No
Desarrollador: Vaimo
Organizado a: Servabelt
Plataforma: Magento Commerce



Usando caché de la página completa: no
Ranking de Alexa: 226247
Hoyer.nr
Sitio: Hoyer.no
Desarrollador: Convertir
Organizado a: océano digital
Plataforma: Magento Commerce



Usando el caché de la página completa: sí
Ranking de Alexa: 442853
Tilbords.nr
Sitio: tilbords.nr
Desarrollador: Vaimo
Organizado en: Glesys
Plataforma: Magento 1.9



Usando caché de la página completa: no
Ranking de Alexa: 334487
Ymeuniverse.com
Sitio: ymeuniverse.com
Desarrollador: Convertir
Organizado a: Servabelt
Plataforma: Magento 1.9



Usando el caché de la página completa: sí
Ranking de Alexa: 91850
Karitraa.com
Sitio: karitraa.com
Desarrollador: Ate
Organizado a: Servabelt
Plataforma: Magento Commerce



Usando el caché de la página completa: sí
Ranking de Alexa: 502283
Stormberg.com
Sitio: Stormberg.com
Desarrollador: Trollweb
Organizado en: Trollweb
Plataforma: Magento Commerce



Usando el caché de la página completa: sí
Ranking de Alexa: 152444
Fjellsport.nr
Sitio: fjellsport.no
Desarrollador: Trollweb
Organizado en: Amazon
Plataforma: Magento Commerce



Usando el caché de la página completa: sí
Ranking de Alexa: 72919
Enklereliv.nr
Sitio: encclereliv.no
Desarrollador: Trollweb
Organizado en: Trollweb
Plataforma: Magento Commerce



Usando caché de la página completa: Dacacssment Alexa: 325308
Voorwinden.nl
Sitio: Voorwinden.nl
Desarrollador:
Organizado a: byte
Plataforma: Magento Commerce
Usando el caché de la página completa: sí



Ranking de Alexa: 921644
Pietzoomers.nl
Sitio: Pietzoomers.nl
Desarrollador:
Organizado a: byte
Plataforma: Magento Enterprise Edition
Usando caché de la página completa: no



Ranking de Alexa: 1507728
Vita.nr
Sitio: Vita.nr
Desarrollador: Trollweb
Organizado en: Trollweb
Plataforma: Magento Enterprise Edition
Usando el caché de la página completa: sí



Ranking de Alexa: 157170
La reflexión sobre la memorización de magento y almacenamiento en caché en caché es un componente de software o hardware que almacena datos, de modo que las solicitudes futuras de los mismos datos se pueden atender más rápido. Es vital acelerar el cálculo y ahorrar recursos y tiempo utilizados para acceder a los datos. El caché se implementa en la mayoría de las capas de una pila de software de servidor web, en el sistema de archivos, la base de datos, el servidor web y las aplicaciones web.
Una percepción común es que los fondos alternativos de almacenamiento de caché y el almacenamiento de caché resolverán los problemas de rendimiento de la tienda. Esto rara vez es cierto. Por experiencia, sabemos que los desarrolladores de Magento están comenzando a pedir un almacenamiento de caché más rápido, como un caché de página completa, como el barniz, cuando se desafían con problemas de rendimiento. La expectativa general es que su instalación y configuración resolverán los problemas de rendimiento, ¡no lo será! Magento Electronic Commerce y el almacenamiento de caché de toda la página Esta prueba muestra que el almacenamiento de la página completa generalmente no proporciona los resultados que los desarrolladores desean lograr. Y es por eso que el caché completo de la página memoriza solo las páginas en su mayoría accesibles en caché tienen muchos cientos, o a menudo miles de páginas diferentes. Los cachés de página completa generalmente no mantienen todo en caché, y los elementos de caché frecuentemente caducan.
Los visitantes del sitio acceden bien a las páginas aleatorias, generalmente vienen en la primera página, pero las páginas que una visita al cliente generalmente son una selección aleatoria. Para que el caché de la página completa sea efectiva, las páginas deben estar listas en el caché cuando se solicite, y si no, el caché de toda la página no ayuda al rendimiento.
Los administradores de Magento eliminan la memoria de caché, siempre memorizando el caché de toda la página contradice el flujo de trabajo diario habitual para los propietarios y administradores de las tiendas.
Las integraciones forzan el refrigerio de la memoria de caché, todo el tiempo muchas tiendas sincronizan sus productos de otras fuentes y, para obtener cambios en línea, el caché se elimina continuamente. El caché de toda la página nunca se aplica al rendimiento de los antecedentes, las listas de pedidos. Pedidos. Pedidos. , Gestión de productos, gestión de categorías y todas las demás tareas de fondo diarias permanecerán lentos y sin caché.
Dados todos estos factores, ¿qué ganancias de rendimiento podemos esperar realmente al implementar el caché de la página completa?¿Cuándo hubiera funcionado el caché?



La respuesta es que el almacenamiento de toda la página proporciona mejoras de rendimiento solo para las páginas accedidas con mucha frecuencia y cuando se enfrentan a los picos de tráfico. Los resultados de la prueba sugieren que las ganancias de rendimiento para el rendimiento diario son muy pequeñas y que el almacenamiento de caché de toda la página es principalmente una herramienta de escala. Los fondos alternativos de almacenamiento en caché y los fondos memcached también se utilizan para cambiar el caché predeterminado de retroceso o base de datos, con Redis o Memcached. Ambas son excelentes aplicaciones, pero generalmente no harán una gran diferencia en el rendimiento para los usuarios del sitio web. La razón de esto es que los fondos alternativos de caché ofrecen solo acceso de lectura y escritura de caché más rápido. El problema más común en Magento no es el acceso a la lectura o la escritura en caché, sino la creación real de caché, que se realiza en MySQL y PHP. Un fondo alternativo de almacenamiento de caché no acelerará el tiempo para crear caché, pero solo proporcionará una forma más rápida de guardar y leer caché. Además, las ganancias de rendimiento de E/S del caché basado en la memoria generalmente están sobrevalorados para Magento. Si tiene una pila de software configurada correctamente que se ejecuta en discos duros SSD con suficiente RAM, los elementos se almacenarán en caché en el sistema de acceso a archivos o de todos modos.

Método de prueba El objetivo de la prueba de rendimiento Magento El objetivo principal de la prueba es recopilar los tiempos de respuesta, la distribución de los tiempos de respuesta e información sobre qué tan bien funciona el almacenamiento de toda la página para el rendimiento. Los resultados proporcionarán una perspectiva interesante sobre la experiencia del usuario para los visitantes de la tienda. Las pruebas se realizaron en la semana 49 y 50 2017 desde los Países Bajos. El método de prueba de rendimiento de Magento Los datos se recopilaron utilizando gritos SEO Spider, con una configuración que solo se hizo cargo de las páginas HTML (sin CSS, JPG, JS, etc.) y evitó las pruebas de páginas utilizando filtros y otros parámetros de no recelación. Para las tres indexación que se ejecutan en el sitio, registramos el tiempo de respuesta promedio para todas las solicitudes y una tabla de respuesta ordenada por segundo. Ejecute 1 – Índice de rollo de prueba inicial durante aproximadamente 5 minutos (indexando entre 350 y 750 páginas). Ejecutar 2 – Prueba de caché de la página completa Rode aproximadamente la misma cantidad de pantalla de página, directamente después de ejecutar el 1 ejecución de la prueba 3 – índice de prueba de confirmación, un número equivalente de vistas de página, unas pocas horas después de la ejecución 1 y 2. El principio es a un Pruebe cómo los usuarios reales experimentan una visita al sitio.
Se espera que la Ronda 1 de la prueba proporcione un instante correcto del rendimiento general del sitio. Ejecutar 2 debe llegar a la memoria caché de toda la página, si está en uso y configurado correctamente, y simularía el rendimiento al enfrentar picos de tráfico repentinos (como sitios al enviar boletines informativos, campañas, etc.). Para los sitios que usan una página de caché completa, esperamos que mejore el tiempo de respuesta promedio y la distribución. La prueba de confirmación, Ejecutar 3, es confirmar que los resultados en la ejecución 1 son correctos y observar cuán pegajoso es el caché de toda la página. Todas las pruebas se realizan en sitios de producción en vivo, como si estuvieran disponibles para todos en Internet. Esto significa que los sitios que usan correctamente la memoria en caché y que tienen mucho tráfico deberían tener una ventaja general en comparación con los sitios de tráfico más bajos y aquellos que no usan almacenamiento de caché. El resumen y las recomendaciones comenzaron este proyecto de investigación para ver cómo los sitios de Magento generalmente se comportan para los usuarios finales, y los resultados están de acuerdo con lo que esperábamos. Las preguntas que queríamos responder y aclarar eran; ¿El almacenamiento en caché de toda la página es una forma viable de resolver problemas de rendimiento de Magento?
¿El reemplazo de backend de caché mejorará el rendimiento de Magento?
¿Hay otras mejores formas de resolver problemas de rendimiento de Magento?
Los problemas de rendimiento para los sitios de Magento a menudo se prueban instalando más aplicaciones, más extensiones y más código. Los resultados muestran que esta suele ser una forma incorrecta de abordar los problemas de rendimiento. Lea la reflexión para averiguar por qué es. ¿Es toda la página almacenado en caché una forma viable de resolver problemas de rendimiento de Magento? Es posible lograr un buen rendimiento implementando el caché de la página completa, sin embargo, solo uno de los 15 sitios probados ha proporcionado un ejemplo de uso eficiente del caché de toda la página para el rendimiento. Para todas las tiendas con tiempos de respuesta medios superiores a 1 segundo, los resultados muestran que los visitantes no acceden a las páginas de caché. Además, mantener toda la página en caché nunca acelerará el rendimiento de fondo. ¿El reemplazo de backend de caché mejorará el rendimiento de Magento? Ninguno de los sitios web alojados por ServBelt usa respaldos alternativos de caché. La razón es que el backend de caché de E/S normalmente no es lo que causa problemas de rendimiento. Si la memoria caché de E/S es el problema, pasar a un caché basado en la memoria ayudará, pero para la mayoría de los sitios Magento, el rendimiento PHP/MySQL es el que ralentiza el sitio. El único medicamento para PHP/MySQL lento es un alojamiento más rápido y mejor. ¿Hay alguna otra forma de lograr una actuación de Magento excepcional?
Para lograr un buen rendimiento, nuestra principal recomendación es enfocar todo el esfuerzo en acelerar el rendimiento no consistente. Esto a menudo puede ser más fácil de decir que hacer, pero para resumir los elementos básicos: use un host rápido con un sistema operativo y una pila de aplicaciones configuradas en consecuencia las configuraciones estándar que obtiene en VPS y servicios en la nube no proporciona un buen rendimiento. .
Remedia Todos los errores conocidos desarrollan que los desarrolladores tienden a ignorar los errores en las revistas del servidor web y las revistas Magento. Cada error hace que la aplicación funcione más lentamente, y resolver problemas reales es mucho más difícil cuando los errores son grandes.
Pruebe todas las páginas para su rendimiento antes de implementar el nuevo código Cuando implementa cambios, asegúrese de que su presente, categoría y páginas de pago sigan respondiendo de manera oportuna. Además, siempre vigile su rendimiento de espaldas.
Seleccione las extensiones para usar con muchas extensiones afectan el rendimiento. Desinstale las extensiones que no usa.
Pruebe su magento con el almacenamiento en caché de toda la página deshabilitada, acepte que la mayoría de los usuarios accederán a páginas que no se almacenan en caché. La memoria en caché de toda la página es para escalar, no para el rendimiento. El rendimiento libre de caché es lo que tienes que ser con tus ojos.