Estás entrando en un amplio y amplio mundo de optimización aquí y allá, ciertamente no hay un enfoque único para todos.
Definir rendimiento
¿Te refieres al tiempo de carga de la página para un solo usuario, o la capacidad total / concurrencia total? Los dos son muy diferentes, y no están estrictamente relacionados. Es completamente posible tener una tienda rápida con capacidad limitada; o una tienda lenta con mucha capacidad.
Entonces, al abordar cualquier tipo de rendimiento:
- Tiempo de carga de página percibido por un solo usuario
- Capacidad total / concurrencia
Debe abordar cada uno de forma independiente con sus propias soluciones, especialmente porque cada uno tiene sus propios cuellos de botella.
Supongamos que está con un host competente que ya ha configurado los otros aspectos de su servidor de manera óptima para su tienda.
Tiempo de carga de página percibido por un solo usuario
¿Es MySQL el cuello de botella?
No. No directamente. Se trata de latencia, en la mayoría de los casos cuando se prueba el tiempo de carga de la página, solo se verán los cachés. Entonces, la clave aquí es minimizar la latencia.
- Ajuste los tamaños de caché de MySQL adecuadamente (no hay una respuesta correcta, ajustamos la configuración de manera completamente diferente, mensualmente, por tienda)
- Reduce la latencia de la red. Para cuadros de 64 bytes; 51,2 µs para 10 Mbps, 5,12 µs para 100 Mbps y 4,096 µs para 1 Gbps. Esto proporciona una mejora del 20% con solo pasar de 100Mbps a 1Gbps. s1
- Aumentar la capacidad de la red. Se sorprendería de los muchos megabytes por segundo que se intercambian entre un servidor web y un servidor de base de datos, por lo general superiores a 10 MB / s, por lo que se requiere un mínimo de 100 Mb / s s1 . O simplemente mueva el servidor de base de datos localmente.
- Usando SOLR. Los motores externos a veces son más adecuados, SOLR ciertamente es más rápido para catálogos MÁS GRANDES (y destacaría, catálogos más grandes ). Incluso SOLR no sintonizado producirá navegación en capas y resultados de búsqueda más rápido que MySQL.
Pero estos cambios tendrán un impacto tan fraccional en el tiempo de carga de la página, donde el cuello de botella está realmente en otra parte.
- Ajusta la aplicación. Magento tiene algunos errores bastante grandes con la forma en que construye colecciones y las almacena en caché; Hemos encontrado una serie de grandes problemas de código central que pueden afectar el rendimiento. En algunos casos, simplemente quitando la pantalla de recuento de productos en los resultados de navegación en capas se ahorraron 2 segundos de cargar una gran colección.
- Revise los registros lentos de MySQL. Verifique las consultas lentas y agregue índices según sea necesario. La diferencia entre ejecutar una consulta compleja con múltiples combinaciones con y sin índices apropiados puede ser decenas de segundos .
La aplicación es el cuello de botella. No es el software. Por lo tanto, simplemente mejorar el código central o hacer que su plantilla sea menos pesada tendrá un efecto mucho más dramático en el rendimiento que CUALQUIER cambio de configuración de MySQL.
¿Con qué no nos molestaríamos?
- Cambio del motor de almacenamiento. MariaDB y Percona comparten el mismo motor InnoDB: Percona XtraDB. Pueden ser tratados como uno y lo mismo. En términos de tiempo de ejecución de una sola consulta, el rendimiento reflejará exactamente una compilación de MySQL estándar. Esto entra en juego bajo carga / concurrencia.
- Ejecutando un esclavo MySQL. Esto no mejorará el rendimiento a menos que el esclavo se encuentre físicamente más cerca (desde una perspectiva de red) o que el esclavo tenga un mejor hardware que el maestro. Esto entra en juego bajo carga / concurrencia.
- Ejecutando un servidor de base de datos externo. Este es, con mucho, el peor consejo que vemos repetidamente entregado por muchos anfitriones / agencias. Hasta que haya alcanzado un límite en hardware / recursos o haya tenido varios servidores web (léase: alta disponibilidad), MySQL en la máquina local para una tienda Magento es una buena idea. Corta toda la sobrecarga y latencia de la red. Incluso una red de 100 Gb / s (sí, cien gigabits por segundo) no se comparará con un socket unix local para volumen, rendimiento y latencia sin procesar.
s1 Solo para servidores de bases de datos independientes. No se aplica a los servidores de bases de datos locales.
Capacidad total / concurrencia
¿Es MySQL el cuello de botella?
Quizás. Pero solo una vez que haya logrado el rendimiento y la capacidad de PHP hasta el punto en que MySQL está ralentizando las cosas. Si tienes Varnish y FPC configurados correctamente (no nos hagas comenzar con cuántos intentos fallidos hemos visto con ninguno de ellos) , entonces MySQL se convierte en un cuello de botella.
Entonces, además de las modificaciones anteriores.
- Cambiar el motor MySQL. XtraDB puede sobresalir bajo carga y muestra beneficios genuinos sobre una distribución MySQL estándar.
- Manténgase actualizado con MySQL. 5.5 funciona mejor que 5.0 bajo carga.
- Cambiar el controlador PHP MySQL. PHP 5.3 y más reciente tiene un controlador MySQL nativo, pero en algunas circunstancias, hemos encontrado PHP 5.2 con el controlador separado para superar a MySQLND para Magento. Pruébalo por ti mismo
- Cambiar motor de búsqueda. Mover la búsqueda a SOLR / Sphinx (o incluso a algunos servicios externos de terceros) realmente puede aliviar la carga de la carga no transaccional (es decir, personas que no hacen pedidos)
- Cambiar el motor de navegación en capas. Nuevamente, SOLR es un motor brillante para la navegación en capas y, debido a su naturaleza sin bloqueo, es mucho más rápido que MySQL.
- Añadir un esclavo MySQL. Esto hace ayuda de navegación de carga (no transaccional), pero no le ayudará a procesar más pedidos por hora - ya que es dependiente de la Maestría de proceso y replicar estos datos
¿Con qué no nos molestaríamos?
- Maestro maestro. Debido al punto de inflexión bastante alto de la saturación de hardware de una configuración Maestro / Esclavo (más de 1000 pedidos por hora), nunca hemos encontrado un requisito para usar Maestro / Maestro en la producción. Hemos realizado pruebas exhaustivas, pero nunca hemos encontrado que sea ventajoso desde una perspectiva de rendimiento y con los riesgos y problemas inherentes de Master / Master, simplemente no vale la pena.
Escalabilidad de lectura vs escritura
El último párrafo realmente conduce a un área clave de escalabilidad de lectura y escritura. El escalado de lectura se puede realizar de manera bastante infinita sin demasiadas complicaciones con la adición de más y más esclavos.
Dada la proporción de lecturas a escrituras de Magento es de aproximadamente 0.1%, teniendo en cuenta que las escrituras no deberían ser una gran preocupación. Es por eso que no me he molestado en mencionar MySQL Cluster y sus características inteligentes como el auto-fragmentación (división de tablas en máquinas separadas).
Hardware, hardware, hardware
El hardware es fácilmente la respuesta más rápida cuando se trata de mejorar, por lo que deliberadamente no lo he mencionado anteriormente en ambos escenarios.
Pero todos los cambios de software en el mundo no harán ninguna diferencia si su hardware subyacente es insuficiente. Eso podría significar ...
- Interruptores de baja calidad con amortiguadores limitados
- Enlaces de red demasiado saturados
- Servidores geográficamente distantes
- Mala red QoS / CoS
- Cantidad total limitada de RAM
- RAM de ancho de banda de memoria baja
- Subsistema de HDD de baja IOP
- Controlador RAID de software
- CPU de baja velocidad de reloj
- Chipset de bajo ancho de banda
- Virtualización de hardware (casi todos los tipos, excepto la virtualización de nivel de kernel)
Hoy en día, hay un techo realmente alto sobre qué tan alto puede escalar realmente en el hardware. Vamos a ignorar el mito de la escala infinita "en la nube", ya que el hardware de la nube tiende a ser bastante mediocre. Por ejemplo, los modelos emblemáticos de Amazon solo tienen 12 núcleos a 3,3 GHz. Pero aparte de esto, hay algunos servidores muy potentes disponibles: nuestro servidor superior tiene 160 núcleos y 2 TB (sí, Terabytes) de RAM. Todavía no hemos visto a nadie superar las capacidades de eso.
Por lo tanto, tiene un alcance masivo para el escalado vertical, incluso antes de que necesite considerar el escalado horizontal.
El objetivo siempre en movimiento
Vale la pena mencionar que en la búsqueda del rendimiento, el cuello de botella siempre se mantendrá en movimiento.
Para una tienda de stock Magento.
Enciende los cachés. PHP es el cuello de botella
Agregar un caché de back-end. PHP es el cuello de botella
Agregue un caché de página completa a nivel de aplicación. PHP es el cuello de botella
Agregue un caché front-end a nivel de servidor (por ejemplo, Varnish). MySQL es el cuello de botella.
Agregue un motor alternativo de búsqueda / navegación por capas (por ejemplo, SOLR / Sphinx). PHP es el cuello de botella
Agregar más servidores de aplicaciones. MySQL es el cuello de botella
Agregar un esclavo MySQL. El caché front-end es el cuello de botella
Agregue más servidores caché front-end. PHP es el cuello de botella
Agregar más servidores de aplicaciones. SOLR / Sphinx es el cuello de botella
Etcetera
Casi se convierte en un caso de repetición de enjuague y lavado. Pero lo que está claro es que MySQL ciertamente no es el primer puerto de escala para la optimización, y realmente solo entra en juego cuando MySQL está consumiendo más CPU proporcionalmente a PHP, y esto SOLO sucede cuando FPC y Varnish están en uso y los servidores solo procesan pedidos y nada más (porque todo lo demás está en cachés).
No hagas cambios a ciegas
Simplemente agregar un esclavo MySQL porque nos leyó decir más arriba que ayudará, puede costarle rendimiento y confiabilidad a un nivel enorme. Una red congestionada, un servidor esclavo de baja especificación o incluso una configuración incorrecta pueden causar problemas de replicación que pueden hacer que su tienda sea más lenta de lo que era en un principio, o causar problemas de sincronización entre el maestro y el esclavo.
Para poner las cosas en perspectiva, algunos ejemplos del mundo real.
Ejemplo 1 - 300 pedidos por hora
Hemos utilizado el siguiente hardware para atender 300 pedidos por hora ; y solo en ese punto de inflexión: sentimos la necesidad de agregar un servidor MySQL dedicado y un esclavo MySQL local.
1
CPU del servidor : 2x Intel E5-4620
RAM: 64GB HDD: 4x 80k IOP / s SSDs
RAID: Hardware RAID 10
Versión Magento: Magento EE
OS: MageStack
Durante todo el tiempo, los promedios de carga permanecieron por debajo de 3.00.
Ejemplo 2 - 180 pedidos por hora
Hace solo dos días, un nuevo cliente nuestro absorbió fácilmente un gran aumento de tráfico. Procesando 180 pedidos por hora con un solo servidor y Magento Community Edition .
1
CPU del servidor : 2x Intel E5-4620
RAM: 64GB HDD: 4x 80k IOP / s SSDs
RAID: Hardware RAID 10
Versión Magento: Magento CE
OS: MageStack
Sitio web: Wellgosh.com
Durante todo el tiempo, los promedios de carga se mantuvieron por debajo de 6.00. La carga fue mayor en este escenario y eso se redujo a un par de factores.
- No se realizó la sintonización del lado de la tienda como en el Ejemplo 1
- La falta de un FPC a nivel de aplicación
Y dada la actualidad de esto, todavía tenemos las estadísticas detalladas para dar algunos comentarios por medio de gráficos. Estos cuentan una excelente historia de cómo se distribuye la carga entre los componentes clave de una arquitectura separada de Magento (equilibrador de carga, servidor web, servidor db, etc. - usando MageStack ).
Entonces, de adelante hacia atrás ... la fecha que desea ver es a las 12:00 a.m. del 22 de febrero.
Paquetes de cortafuegos
Tráfico de barniz
Tráfico Nginx
Carga MySQL
Carga de la CPU
Y lo más importante, distribución de carga.
Esta imagen realmente lo dice todo. Y es que MySQL ciertamente no es una carga, al menos no todavía. Por lo tanto, nuestro consejo, concentre sus preocupaciones de rendimiento en otro lugar, a menos que esté procesando más de unos pocos miles de pedidos por hora.
Y en resumen
Hacer cambios en el rendimiento no es "una talla para todos". Se trata de analizar sus cuellos de botella actuales y hacer cambios / ajustes sutiles para adaptarse a su tienda e infraestructura.
Pero dejando de lado el rendimiento, hay otros beneficios al usar Percona
Usamos Percona XtraDB, casi exclusivamente. Ejecutamos compilaciones personalizadas de MySQL que desarrollamos específicamente para Magento y que habíamos consultado a Percona durante el proceso. Pero no fue solo el rendimiento lo que influyó en esta elección.
- El kit de herramientas de Percona
- pt-query-digest
- xtrabackup
- etc.
- Frecuencia de liberación de Percona
- Percona consultivo
- El caché cálido se reinicia con la preservación de la agrupación InnoDB
Y mucho más. Por lo tanto, usarlo sobre MySQL tenía otras ventajas además del rendimiento. De hecho, MySQL es y siempre ha sido la menor de nuestras preocupaciones en la búsqueda del rendimiento y la estabilidad.
Atribuciones: wellgosh.com , sonassi.com , iebmedia.com .