Actualmente estamos trabajando con el requisito de que la primera respuesta del servidor web debe ser inferior a 200 ms en el Reino Unido. Actualmente bajo 2 servidores web dedicados bajo balanceador de carga y 1 servidor de base de datos, estamos llegando a 800ms.

El sitio en este momento tiene menos de 5 clientes, 2 productos, 4 categorías, no hay interfaz para el sitio en este momento, no tiene estilo ni imagen.

También se ejecuta en nginx con Varnish.

¿Alguien puede darme algún consejo sobre la configuración del servidor web? ¿Por qué viene el nuestro lentamente? ¿Qué me puede recomendar para optimizar esto? ¡Necesitas obtener un 400% más rápido!

Morderé.

Esa primera respuesta del servidor web debe llegar a menos de 200 ms en el Reino Unido.
No hay una interfaz para el sitio en este momento, no tiene estilo ni imagen.

No logrará esas cifras sin la ayuda de Varnish o FPC (o ambos). Ciertamente, espero que esa cifra no tenga que incluir contenido estático (cada vez que decida agregarlo), ya que es casi imposible de lograr (salvo tener pocas o ninguna imagen / js / css).

Estamos llegando a 800 ms.
También se está ejecutando en Nginx con Varnish

Tienes Varnish configurado incorrectamente.

Una instalación correctamente configurada de Varnish proporcionará tiempos de carga de página de <100 ms (vemos más cerca de <10 ms).

De hecho, para Magento, debe esperar ver algo como esto,

Cuando un cliente no ha iniciado sesión ... Es
decir. No haber creado una sesión única (agregar al carrito / lista de deseos, iniciar sesión, etc.)

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

Cuando un cliente inicia sesión ... Es
decir. Haber creado una sesión única (iniciada sesión, artículos en el carrito, etc.). En este punto, el barniz probablemente estará apagado. Y si ha optado por usar ESI, dependiendo de las llamadas inversas, puede mantener un tiempo de carga de página similar al del caché FPC (debido a los gastos generales de arranque), o en realidad aumentar los tiempos de carga de la página más allá de la memoria caché.

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache   

No es un caso de sintonizar Varnish, es un caso de "en realidad no está almacenando nada en caché" .

Los archivos de configuración del servidor Magento ideales

No hay uno, bueno, no del todo.

Operamos más de 400 servidores, todas tiendas puramente de Magento, de diferentes tamaños y capacidades. Y es raro que los archivos de configuración que tenemos en uno coincidan con los de otro. Eso es porque no todas las empresas son iguales.

Se pueden formar cuellos de botella debido a muchas razones diferentes:

1. Gran cantidad de concurrencia de visitantes, con sesiones activas
2. Las víctimas de los robots de rastreo "malos" generan una carga necesaria e invaluable
3. Alta proporción de golpes de navegación en capas
4. Alto número de consultas de búsqueda.
5. Alto volumen de transacciones por hora.
6. Plantilla mal construida
7. Demasiadas / lentas / voluminosas extensiones de terceros
8. Enlaces entrantes desactualizados que conducen a una alta proporción de 404 hits
9. Capacidad de interfaz de red al límite
10. Catálogo grande / complejo (muchos productos / categorías / atributos)

Entonces, con tiendas en todo este espectro, cada una tiene un enfoque diferente para un rendimiento más óptimo.

Para resolver los problemas descritos anteriormente; evitaremos deliberadamente simplemente decir "más / mejor hardware"

1. Usa un FPC más allá del barniz
2. Filtre / bloquee los bots defectuosos en el borde de la red, o redirija todas las solicitudes a Varnish independientemente del estado de la cookie / URL
3. Cambie la navegación en capas de stock a SOLR, haga que los filtros de navegación en capas dependan
4. Cambiar búsqueda de stock a SOLR
5. Distribuya la carga de MySQL en la configuración Maestro / Esclavo: solo haga esto cuando haya garantizado que Varnish / FPC absorba la carga de navegación
6. Reconstruir la plantilla
7. Pelarlos
8. Monitoree los registros de acceso continuamente y reescriba las URL en Nginx / Varnish antes de la entrega. Si lo hace a nivel Nginx, asegúrese de que Varnish esté almacenando en caché las redirecciones 301/302.
9. Divida el contenido estático en un CDN o mejore la conectividad
10. Agregue más hardware (bueno, tuvimos que decirlo en algún momento)

Entonces, teniendo esto en cuenta, verá que probablemente no habrá un archivo de configuración de Nginx, un archivo de configuración del grupo PHP fcgi, un archivo de configuración MySQL o un archivo de configuración Varnish que serán los mismos. Combina eso con los cambios de hardware en sí mismo; memoria disponible, rendimiento de E / S (HDD y red) y CPU, y descubrirá que hay variaciones sutiles que conducen al aumento de rendimiento del 400% que desea, pero no encontrará una respuesta rápida en línea.

Puede copiar + pegar el informe técnico patrocinado por Peer 1 sobre rendimiento (no lo recomendaríamos); Esperamos que la configuración no exceda su memoria disponible, límites de subprocesos, estados de TCP / IP, capacidad de E / S y conduzca a un rendimiento menor que una configuración de Apache / mod_php.

Entonces continuemos.

La pila de servidores Magento ideal

Es más probable que esto te acerque a la realidad. Un buen ejemplo para demostrar esto es mostrar cómo se configura un sistema operativo Magento dedicado, MageStack

Tome los subcomponentes por separado y obtendrá una lista del software más óptimo / crítico, cuando está configurado correctamente , para ejecutar una tienda Magento. Notablemente:

Cortafuegos, filtro DOS, Load Balancer, Varnish, Nginx, PHP, Redis, Memcached, MySQL

Entonces cuando preguntas:

¿Cuál es la mejor configuración del servidor Magento?

¿Cuál es tu objetivo exactamente?

1. Alta disponibilidad
2. Fiabilidad
3. Simplicidad de administración
4. Actuación
5. Escalabilidad

Basta de conferencias, ¿cómo lo haríamos?

Para reflejar parcialmente la respuesta dada en la falla del servidor por una vena similar. Tiene 3 servidores a su disposición, así que primero oriéntelos de la manera más óptima posible. Evitaremos una solución de alta disponibilidad, ya que está mucho más allá del alcance de esta respuesta.

Los subcomponentes necesarios para una configuración multiservidor son:

• Cortafuegos
• Equilibrador de carga
• Servidor web
• Servidor MySQL
• Almacenamiento común

Entonces, utilizaremos varios de los sistemas. El cumplimiento de PCI-DSS dicta un rol para cada servidor. Entonces, con 5 roles y 3 servidores, estará en incumplimiento de inmediato. MageStack soluciona esto mediante la virtualización: usted podría hacer lo mismo.

Servidor 1: Load Balancer + servidor web
Servidor 2: servidor web
Servidor 3: servidor de base de datos

Sin baja latencia y un ancho de banda de red significativo (> 1 Gbps, <125 µs), en lugar de tener un almacenamiento común, es mejor para usted simplemente almacenar el directorio raíz de la tienda en cada máquina y replicar los datos, ya sea en tiempo real usando ionotifyo caducado usando un crontrabajo Nuevamente, evitaremos los sistemas de archivos de red como NFS o los dispositivos de bloque replicados como Gluster o DRBD, ya que se requiere una gran sintonización y un ancho de banda de red decente.

Barniz necesita sentarse lo más cerca posible del frente. Pero Varnish no puede descifrar SSL. Entonces combínelo con un terminador SSL; Nginx, Pound, Stunnel, Stud, etc. El equilibrador de carga incorporado en Varnish no es excelente, pero sería adecuado para una configuración de 2 servidores.

Nginx + PHP-FPM está bien, pero no bebas demasiado de Nginx kool-aid. Funcionará de manera casi idéntica a una configuración tradicional de Apache / mod_php, aquí hay algunas buenas lecturas sobre por qué no usar Nginx . Nginx es bueno, de hecho, muy bueno, pero ciertamente no es un cuello de botella de una tienda Magento, y dada su complejidad y la falta de soporte nativo de Magento. La mayoría de los administradores de sistemas novatos se beneficiarían del uso de Apache / mod_php sobre cualquier otra cosa. Esto puede parecer una recomendación arcaica sobre el uso de PHP-FPM, pero nuestras pruebas de rendimiento han demostrado que el rendimiento es solo ~ 7% más rápido con la solución Nginx, cuando está configurado correctamente. El ajuste y la experiencia requeridos para una configuración Nginx / PHP-FPM confiable y de alto rendimiento es bastante amplia para superar a Apache / mod_php. Cualquiera que elija usar, es su decisión.

El servidor de la base de datos es simple, MySQL. Pero como se mencionó anteriormente, si tiene un sitio de alta conversión, se recomienda una configuración Maestro / Esclavo. Puede leer si debe seguir este enfoque leyendo este artículo .

Luego, sus cachés de back-end periféricos, Memcached y Redis. En tiendas más pequeñas, almacenar sesiones en una instancia de Memcache y la memoria caché de back-end rápida en otra producirá buenos beneficios de rendimiento. No recomendamos almacenar las etiquetas de caché en un backend lento, ya que causa más problemas de los que da. Entonces, con una configuración de Memcached, tendrá que perder el etiquetado de caché . En cambio, usamos una configuración como esta .

Redis no es nativo de Magento, pero con la extensión de Colin Mollenhour , es una solución mejor que Memcache, admite etiquetas de caché, almacenamiento de sesión e incluso almacenamiento de caché persistente, no es tan volátil como Memcache . Pero tiene sus inconvenientes. Hemos encontrado en tiendas de producción a gran escala (> 500 pedidos / hora,> 30k únicos / hora) que el caché (y las etiquetas) pueden llenarse muy rápidamente y una vez que se alcanza el punto de saturación, el mecanismo LRU falla algo ( a pesar de diferentes configuraciones) y provoca un cuello de botella inmediato masivo. Por lo tanto, es prudente podar regularmente los registros antiguos manualmente.

Entonces, ¿qué hardware se debe utilizar para qué?

Servidores web: CPU más rápida, la mayoría de los núcleos de CPU, relación de 2 GB de RAM /
servidor Core DB: CPU rápida, E / S de disco más rápida, la mayoría de RAM

Entonces, cuando se utilicen sus 3 máquinas para múltiples propósitos, el mejor diseño sería:

Servidor 1: Terminador SSL -> Barniz -> Nginx / Apache> PHP
Servidor 2: Nginx / Apache> PHP, Redis, (MySQL Slave)
Servidor 3: MySQL

En cuanto a la configuración específica de cada aplicación. Bueno, eso depende de sus especificaciones de hardware, la complejidad de su tienda, su tipo y naturaleza de visitante y el gran volumen de visitantes.

Estás en un gran camino con esa configuración de clúster. Recomiendo agregar un host de caché dedicado para Redis; seleccione uno con alta potencia de CPU y mucha RAM (~ 64 GB).

Aquí está la lista completa de configuraciones que he usado para un clúster LEMP altamente disponible, tolerante a fallas, distribuido y con equilibrio de carga. Incluye app/etc/local.xmlla core_config_datatabla y las configuraciones para MySQL, php-fpm, nginx y Redis. Todos ejecutan Ubuntu 12.04 LTS de 64 bits. Las configuraciones incluyen muchas optimizaciones sin inconvenientes.

Reflejos

• Usuarios administradores: 46
• Categorías: 2,450 (la más grande tiene 2,400 productos)
• Entidades de producto: 101,000
• Productos combinados: 484
• Relaciones de producto: 54,000
• En stock y productos configurables habilitados: 10.100
• Bloques CMS: 3.100
• CMS páginas: 1,400

Tráfico de agosto de 2013:

• 40 millones de visitas mensuales
• 2,3 millones de visitantes únicos
• 46,000 pagos mensuales
• 89% de los visitantes de los EE. UU.

Servidores web

Hay 10 hosts detrás de firewalls de hardware redundantes y de alta disponibilidad y equilibradores de carga de hardware. La mayoría de los activos estáticos se descargan en una CDN.

• tiempo de respuesta promedio en todo el sitio: 282 ms
• Respuesta promedio de FPC: 48 ms
• promedio de carga: 0.6 a 1.0 (en pruebas, el rendimiento se degrada en un 35% cuando los promedios de carga alcanzan ~ 5.0)
• Doble CPU Intel Xeon E3-1230 V2 @ 3.30GHz (4 núcleos cada uno)
• 32 GB DDR3 1333 MHz RAM

Módulos

• https://github.com/colinmollenhour/Cm_RedisSession
• https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
• https://github.com/aligent/CacheObserver.git --branch = modelos
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMenu.git --branch = producción
• https://github.com/Vinai/customer-activation
• https://github.com/gknoppe-guidance/magento-cachebuster

Caché hosts

Hay dos hosts que ejecutan Redis en una configuración maestro-esclavo con conmutación por error automática. Se utilizan tres instancias de Redis (sesiones, back-end y FPC) para aumentar el rendimiento y proporcionar un ajuste fino de los comportamientos de persistencia.

• 3.000 comandos por segundo
• Tiempo de respuesta promedio de 0.7 ms
• promedio de carga de 1.0 a 1.5
• CPU Intel Xeon Quad E5-2620 0 @ 2.00GHz (6 núcleos cada uno)
• 128 GB de RAM DDR3 con memoria intermedia de 1333 MHz
• Discos mecánicos, RAID 1, controlador de hardware

Hosts de bases de datos

Hay dos hosts que ejecutan MySQL 5.6.11 en una configuración maestro-esclavo con conmutación por error cálida.

• 1,500 comandos por segundo
• 1.1 ms de tiempo de respuesta promedio
• promedio de carga de 0.1 (maestro) y 0.4 (esclavo)
• CPU Intel Xeon Quad E7- 2860 @ 2.27GHz (10 núcleos cada uno)
• 128 GB de RAM DDR3 con memoria intermedia de 1333 MHz
• SSD, RAID 1 + 0, controlador de hardware
• MySQL 5.6.11 con tcmalloc

Otro consejo para Magento debe ser instalar PHP 5.4 o 5.5 con OPcache . PHP 5.4 es mucho más rápido que 5.3 ( http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/ ).

Quiero agregar otro consejo importante que mejoró la velocidad de la página de magento cuando no está en caché por barniz y no está habilitado de forma predeterminada (el tiempo de carga de la página del carrito cambió de 6sc a 1.5sc).

Active la caché de consultas mysql en /etc/mysql/my.conf

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

el tipo de caché lo habilita, el tamaño de caché es el valor utilizado por el caché en la memoria y el límite de caché es el tamaño máximo del resultado de la consulta al caché

Con nuestra configuración actual, estamos recibiendo una respuesta inicial en 400 ms y el documento completo en 2 segundos (usando una conexión estándar de 5mbps). El tamaño de nuestra página de inicio es de 1mb.

Nuestra configuración se basa en AWS de la siguiente manera: tenemos una instancia ec2 con un equilibrador de carga conectado a una base de datos RDS (con conmutación por error). También hemos implementado caché de página completa con un backend de caché redis para el almacenamiento de caché y el almacenamiento de sesión.

En promedio, tenemos de 300 a 400 visitantes por día, pero con el almacenamiento en caché de redis habilitado, hemos tenido un uso mínimo de recursos ec2, manteniendo la velocidad y reduciendo los costos.

La razón por la que tenemos un equilibrador de carga es que el ec2 está configurado para iniciar automáticamente una nueva instancia si existe la rara posibilidad de que tengamos picos de tráfico que la configuración actual no puede manejar.