Cómo medir WooCommerce en temporada alta antes de cambiar de servidor

Volver al Laboratorio · Laboratorio / WooCommerce / Método

Para decidir si una tienda necesita más CPU, más memoria o una mejor distribución de recursos, primero hay que observar qué ocurre cuando sus compradores llegan juntos.

Protocolo propuesto el 19 de octubre de 2026. Este artículo presenta el diseño de la medición; los ensayos de carga de WooCommerce todavía no se han ejecutado.

En nuestra primera comparación de cinco servidores medimos compresión y hashing. Conservamos las muestras y repetimos cada tarea tres veces, con un máximo de dos hilos. Eso nos permitió comparar esos trabajos concretos. Para elegir dónde alojar varias tiendas necesitamos otra evidencia: cómo responde la aplicación durante la navegación, el carrito y la compra, y qué ocurre cuando varias instalaciones comparten recursos.

El método que proponemos conecta la operación con el laboratorio. Primero observamos una campaña real. Después construimos un perfil saneado y lo reproducimos sobre una tienda de pruebas. Así podremos estudiar crecimiento y convivencia sin convertir una cifra de CPU en una cantidad de clientes prometida.

1. 01Observar

   Tráfico y recursos durante la operación.

2. 02Perfilar

   Rutas, ritmos y operaciones representativas.

3. 03Reproducir

   Misma aplicación en un entorno aislado.

4. 04Decidir

   Capacidad, margen y coste comprobados.

Cien pedidos diarios no describen un pico de trabajo

Consideremos dos tiendas hipotéticas, ambas con cien pedidos en un día. En la primera, esos pedidos se reparten durante diez horas. En la segunda, se concentran en veinte minutos. La concentración media de pedidos durante esas ventanas difiere treinta veces. Todavía no sabemos cuántas solicitudes HTTP, búsquedas o carritos hubo en cada caso.

Una visita puede consultar varios productos y abandonar el carrito. Un bot puede generar muchas solicitudes sin comprar. Una tarea de importación puede competir con las compras. Por eso registraremos actividad comercial y solicitudes por separado, indicando la hora, el tipo de operación y los trabajos simultáneos.

Separar caché, navegación y operaciones de compra

Una portada entregada desde caché puede exigir un trabajo muy distinto al de calcular un carrito o validar una compra. WooCommerce indica que carrito, Mi cuenta y checkout deben permanecer dinámicos porque contienen información específica de cada comprador. La documentación oficial de caché explica esas exclusiones.

Nuestro registro separará las familias de rutas y, cuando la fuente lo permita, los aciertos y fallos de caché. Una respuesta desde el CDN describe el servicio en el borde; una medición del origen describe el trabajo que recibió el servidor. Conservaremos ambas perspectivas sin sumarlas como si fueran solicitudes distintas del comprador.

Mirar respuesta y recursos en la misma línea de tiempo

Proponemos agrupar tráfico y recursos en intervalos de un minuto, conservando mayor resolución si ya está disponible. La fecha se guardará en UTC y se presentará también en la zona horaria comercial. Marcaremos los huecos de observación y los cambios de configuración. Una campaña puede comenzar antes del evento oficial.

Una RAM aparentemente llena merece una lectura cuidadosa. Linux utiliza memoria para caché; MemAvailable estima cuánto puede destinar a nuevas aplicaciones sin recurrir a swap. Lo relacionaremos con actividad de intercambio, errores y respuesta. El porcentaje ocupado, por sí solo, no identifica un problema. Véase la referencia de memoria del kernel Linux.

Cuando una instalación usa PHP-FPM, su estado puede informar cuántas solicitudes esperan un proceso libre y si se alcanzó el máximo de procesos. Es información útil para estudiar colas; su consulta debe permanecer restringida. Otros motores necesitan su telemetría equivalente. La referencia oficial de PHP-FPM define estos contadores.

Conservar lo necesario para calcular un p95 válido

El p95 describe un punto de la distribución de tiempos: aproximadamente el 95 % de las observaciones quedan en ese valor o por debajo. Para calcular el del evento necesitamos las duraciones individuales saneadas o histogramas compatibles que puedan combinarse. Promediar los p95 de cada hora no produce el p95 del día. La documentación de Prometheus explica la diferencia entre cuantiles precalculados e histogramas agregables.

Separaremos respuestas correctas y fallidas, y mostraremos también el total de intentos. Un conjunto de errores rápidos no debe hacer parecer más rápida una tienda. Si solo conservamos promedios diarios de comprobaciones de disponibilidad, podremos estudiar esas comprobaciones; no podremos reconstruir las latencias de compra de los clientes.

Las señales de tráfico, latencia, errores y saturación ayudan a formular preguntas sobre la operación. El marco de monitoreo de Google SRE ofrece una referencia útil. El protocolo añade la separación por operación de WooCommerce y las condiciones comerciales de cada ventana.

Reproducir el perfil sobre una tienda aislada

La primera fase observará el tráfico comercial mediante fuentes existentes o una instrumentación aprobada previamente. La segunda utilizará instalaciones desechables, datos sintéticos o anonimizados y un generador de carga separado. Sus pagos serán simulados y sus correos, facturación, transportistas, publicidad y automatizaciones quedarán aislados de los servicios reales.

Las instalaciones conservarán versiones, contenido representativo, base de datos inicial, configuración y condiciones de caché comparables. Documentaremos el presupuesto de recursos de cada plan. Comparar un plan de 64 GB con otro de 32 GB responde una pregunta comercial sobre esos paquetes; no aísla el efecto de la arquitectura del procesador.

Definiremos la carga en solicitudes al origen por segundo y recorridos iniciados por segundo. Son unidades diferentes: un recorrido puede producir varias solicitudes. Antes de fijar el ritmo, una prueba funcional de baja carga permitirá comprobar qué genera cada recorrido. Un modelo de llegada controlada ayudará a detectar cuándo el servidor deja de completar la carga ofrecida; véase la explicación de modelos abiertos y cerrados de k6.

Medir crecimiento y convivencia

La secuencia propuesta comienza con una comprobación funcional. Después ensaya fracciones y múltiplos de un pico observado, con límites explícitos, y añade una prueba de varias horas. Solo entonces aumenta la cantidad de instalaciones o introduce el pico de una tienda junto a otras con carga estable. Es una aplicación del enfoque progresivo descrito por los tipos de pruebas de k6; los ritmos y duraciones concretos de nuestro protocolo son decisiones de diseño pendientes de validar.

Cada tienda tendrá sus propias sesiones, datos y métricas. Informaremos si comparten base de datos, procesos o caché, porque eso cambia el significado del resultado. Repetiremos las condiciones desde un estado conocido y alternaremos el orden entre servidores. Los fallos y las corridas incompletas se conservarán.

Antes del ensayo fijaremos los objetivos de latencia y error, la carga máxima autorizada y las condiciones de parada. Un perfil solo se considerará admitido si completa el trabajo previsto, mantiene la corrección de carrito y pedido y satisface esos objetivos durante toda la ventana evaluada. También observaremos el generador: una máquina que no logra emitir la carga no demuestra un límite del servidor evaluado.

Decidir con capacidad medida y costes comparables

La capacidad útil será una combinación de perfil, ritmo, duración y objetivo de servicio. Si una configuración admite cuatro tiendas con el perfil ensayado, eso describirá cuatro instalaciones bajo esas condiciones, no cualquier grupo de cuatro negocios. Dejaremos margen operativo para demanda inesperada, mantenimiento y crecimiento.

Al comparar costes registraremos fecha, moneda, impuestos, plazo, almacenamiento, respaldos y administración. El coste por instalación será orientativo mientras no exista una cantidad admitida y comprobada. Nuestra referencia histórica de precios ya conserva esas distinciones para los planes de la primera serie.

La siguiente evidencia que necesitamos es una línea de base con cobertura conocida y un perfil reproducible. Con ella podremos publicar qué ocurrió durante una campaña, qué logramos reproducir en el laboratorio y cómo cambió la respuesta al compartir servidor.

Este método amplía las pruebas acotadas de CPU. Aún no establece un ganador de WooCommerce, una cantidad de clientes por servidor ni un nivel de servicio contratado.