Sometimos a prueba de carga una tienda de moda activa en su propio servidor de 2 vCPU, con recorridos reales de compra enviados desde el país de cada comprador. Aquí te mostramos su capacidad, cómo lo medimos y por qué sigue siendo rápido a medida que tu negocio crece.
40 compradores al mismo tiempo en 2 vCPU: ≈0.4 s por página en condiciones típicas, 83–89 ms de tiempo de servidor y 99.97% sin errores.
La aplicación, PostgreSQL, Redis y los procesos en segundo plano compartieron un mismo servidor de 2 vCPU con 3.8 GB de RAM.
Página típica en 0.24–0.52 s y el 5% más lento por debajo de 1.5 s, con la CPU a media carga o menos.
Página típica de cerca de 0.4 s, con la CPU al 58–83% y todavía queda margen.
Con 12–14 solicitudes por segundo, el mismo servidor pequeño aguanta una hora de compras intensa.
El contenedor web se mantuvo en 225–262 MiB durante toda la ejecución, con más de 2.4 GB de RAM libres.
Medido para un comprador con sesión iniciada y sin caché de página: el caso más exigente para el servidor.
La búsqueda de productos tarda unos 170 ms de tiempo de servidor en el mismo equipo pequeño.
Los números en los que puedes confiar se basan en condiciones que reconoces, así que medimos cómo llegan realmente tus compradores.
Un catálogo real de moda y un checkout, en un servidor de 2 vCPU y 3.8 GB, con todo en una sola máquina.
70% de visitantes nuevos, entre una y cuatro páginas por visitante, con búsquedas, adición al carrito y 5–15 segundos de lectura entre clics.
k6 envió tráfico desde el país de los compradores, con gzip activado, y cada comprador virtual tuvo su propia sesión.
La red y TLS se incluyeron en los tiempos de página; sin caché de página en los tiempos de servidor, y con PHP-FPM estándar y OPcache.
No necesitas comprar una mejora de servidor. La velocidad viene de cómo está construida y verificada la aplicación.
La página típica (p50) y el 5% más lento (p95), con tiempos medidos de extremo a extremo desde el país de los compradores, junto al tiempo de servidor, la tasa de éxito y el consumo de memoria de la misma prueba.
Cada página se renderiza en el servidor y se puede leer antes de que se ejecute cualquier script. Los datos que son iguales para todos los visitantes se entregan como archivos en caché, y los módulos arrancan solo cuando una solicitud los necesita.
Estos resultados se obtienen con PHP-FPM estándar y OPcache. Sin Octane, Swoole, FrankenPHP ni JIT, mantienes la misma velocidad en cualquier servidor Linux con Docker y sin nada exótico que mantener.
Antes de preparar una versión, se ejecutan el análisis estático y más de 14,000 pruebas automatizadas, para que ninguna función nueva haga que tu tienda pierda velocidad o confiabilidad sin que te des cuenta.
La aplicación está limitada por la CPU y no guarda estado local, por lo que la capacidad aumenta con los núcleos: pasa a 4 vCPU, asigna un servidor propio a la base de datos y luego agrega servidores de aplicación detrás de un balanceador de carga.
Sí, en un servidor comparable de 2 vCPU ubicado cerca de tus compradores. Los tiempos de carga incluyen la red, por lo que la cercanía del hosting a tus clientes importa tanto como el tamaño del servidor.
Personas que navegan activamente al mismo tiempo, con 5–15 segundos de lectura entre clic y clic. Una tienda con 40 personas a la vez atiende a miles de visitantes al día.
Primero, pasa a 4 vCPU; después, asigna un servidor propio a la base de datos y, por último, agrega servidores de aplicación detrás de un balanceador de carga. El software y los datos no cambian en ninguna etapa.
Sí. Las páginas públicas se guardan en caché por host e idioma, por lo que las visitas posteriores no consultan la base de datos. Además, puedes agregar un CDN delante. Los tiempos del servidor que se muestran en esta página se midieron sin caché de páginas.
No los necesitas. PHP-FPM estándar mantiene el hosting simple y predecible, y la aplicación ya es lo bastante eficiente para funcionar rápido sin un entorno de ejecución especial.
Crea tu plan, despliega con Docker y comprueba la velocidad con tu propio catálogo.
