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:
- Gran cantidad de concurrencia de visitantes, con sesiones activas
- Las víctimas de los robots de rastreo "malos" generan una carga necesaria e invaluable
- Alta proporción de golpes de navegación en capas
- Alto número de consultas de búsqueda.
- Alto volumen de transacciones por hora.
- Plantilla mal construida
- Demasiadas / lentas / voluminosas extensiones de terceros
- Enlaces entrantes desactualizados que conducen a una alta proporción de 404 hits
- Capacidad de interfaz de red al límite
- 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"
- Usa un FPC más allá del barniz
- 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
- Cambie la navegación en capas de stock a SOLR, haga que los filtros de navegación en capas dependan
- Cambiar búsqueda de stock a SOLR
- 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
- Reconstruir la plantilla
- Pelarlos
- 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.
- Divida el contenido estático en un CDN o mejore la conectividad
- 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?
- Alta disponibilidad
- Fiabilidad
- Simplicidad de administración
- Actuación
- 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.