Prueba de carga de su plataforma de comercio electrónico: preparación para el tráfico del Black Friday

Shopify informó que los comerciantes ganaron colectivamente $9.3 mil millones en ventas durante el Black Friday/Cyber ​​Monday de 2024, y cada minuto de inactividad durante esas 96 horas cuesta miles de dólares en ingresos perdidos. Las pruebas de carga son la diferencia entre una plataforma que escala con gracia durante el pico de tráfico y una que falla en el peor momento posible. Sin embargo, la mayoría de las empresas descubren el punto de ruptura de su plataforma durante el evento real y no durante las pruebas.

Conclusiones clave

• Prueba de carga con patrones de tráfico realistas, no solo recuentos de solicitudes sin procesar: modele los recorridos reales de los usuarios desde la navegación hasta el pago
• Comience las pruebas de carga entre 8 y 12 semanas antes de los eventos pico para dejar tiempo para cambios en la infraestructura y optimización del código.
• Identifique los cuellos de botella progresivamente: aumente desde la línea base hasta el doble del pico esperado, probando cada capa de forma independiente
• El análisis posterior a la prueba es tan importante como la prueba en sí: correlacione los tiempos de respuesta con las métricas de la infraestructura para encontrar la verdadera restricción.

---

Comparación de herramientas de prueba de carga

La elección de la herramienta de prueba de carga adecuada depende de las habilidades técnicas, la infraestructura y los requisitos de prueba de su equipo.

k6: recomendado para la mayoría de los equipos

k6 es nuestra herramienta recomendada para la mayoría de las pruebas de carga de comercio electrónico. Utiliza JavaScript para scripts de prueba, se integra con canalizaciones de CI/CD y produce métricas detalladas que incluyen percentiles de tiempo de respuesta, rendimiento y tasas de error. Se ejecuta localmente o en la nube y su salida se integra con los paneles de Grafana para un monitoreo en tiempo real.

Las pruebas de k6 definen usuarios virtuales (VU) que ejecutan escenarios: secuencias de solicitudes HTTP que simulan el comportamiento del usuario. Cada VU mantiene su propio estado de sesión (cookies, encabezados), lo que permite flujos de trabajo autenticados realistas.

Artillería: lo mejor para una configuración rápida

Artillery utiliza una configuración basada en YAML para escenarios comunes y admite JavaScript para lógica compleja. Destaca en las pruebas de carga de inicio rápido en las que necesita resultados en minutos en lugar de horas de secuencias de comandos. También tiene soporte nativo para pruebas de Socket.io y WebSocket.

---

Modelado de patrones de tráfico realistas

El mayor error en las pruebas de carga es enviar tráfico uniforme que no coincide con el comportamiento real del usuario. El tráfico real tiene patrones específicos que exponen diferentes cuellos de botella.

Modelado del recorrido del usuario

Una prueba de carga de comercio electrónico debe modelar recorridos completos de los usuarios, no solo visitas a puntos finales individuales. Una prueba realista incluye los siguientes tipos de usuarios con proporciones adecuadas:

Patrones de rampa de tráfico

No salte directamente a la carga máxima. Aumente gradualmente para identificar los puntos de ruptura.

Patrón de aceleración para las pruebas del Black Friday:

1. Línea de base (0-10 minutos): comience con el tráfico diario normal para establecer una línea de base de rendimiento.
2. Aumente hasta el pico esperado (10-30 minutos): aumente gradualmente hasta alcanzar el tráfico esperado del Black Friday
3. Mantener el pico (30-60 minutos): mantener la carga máxima para probar el rendimiento sostenido y las fugas de recursos
4. Prueba de pico (60-70 minutos): simule el inicio de la venta flash con un pico de tráfico de 3 a 5 veces mayor en 30 segundos.
5. Recuperación (70-80 minutos): vuelva a la carga normal y verifique que el sistema se recupere sin intervención manual
6. Prueba de inmersión (ejecución separada, 4-8 horas): carga moderada sostenida para detectar pérdidas de memoria y agotamiento del grupo de conexiones

Piense en el tiempo y el ritmo

Los usuarios reales no envían solicitudes lo más rápido posible. Leen contenido, comparan productos y completan formularios. Incluya tiempos de reflexión realistas entre solicitudes:

• Entre vistas de página: 5-30 segundos
• Llenar el formulario de pago: 30-120 segundos
• Lectura de descripciones de productos: 10-60 segundos
• Buscar y filtrar: 3-10 segundos entre acciones

Sin tiempos de reflexión, su prueba genera una carga concentrada de manera irreal que no coincide con los patrones de tráfico de producción.

---

Identificación de cuellos de botella

Las pruebas de carga revelan cuellos de botella, pero es necesario saber dónde buscar. Supervise las métricas de infraestructura junto con los resultados de las pruebas para correlacionar la degradación del tiempo de respuesta con el agotamiento de los recursos.

Cuellos de botella en la base de datos

Síntomas: Los tiempos de respuesta aumentan linealmente con la carga, la CPU de la base de datos está al 90 % o más, el registro de consultas lento se llena rápidamente

Causas comunes:

• Faltan índices en columnas consultadas con frecuencia
• N+1 consultas que se multiplican con usuarios concurrentes
• Bloquear la contención sobre las actualizaciones de inventario durante el pago
• Agotamiento del grupo de conexiones (todas las conexiones en uso, cola de nuevas solicitudes)

Diagnóstico: Supervise pg_stat_activity para consultas activas, pg_stat_user_tables para recuentos de análisis secuenciales y métricas del grupo de conexiones. Consulte nuestra guía detallada sobre optimización de consultas de bases de datos.

Cuellos de botella del servidor de aplicaciones

Síntomas: La CPU aumenta al 100 %, el retraso del bucle de eventos aumenta (Node.js), las pausas en la recolección de basura causan picos de latencia

Causas comunes:

• Operaciones sincrónicas que bloquean el bucle de eventos (procesamiento de imágenes, generación de PDF)
• Pérdidas de memoria que provocan una recolección de basura cada vez más frecuente.
• Procesos de trabajo insuficientes para operaciones vinculadas a la CPU
• Falta almacenamiento en caché para cálculos costosos

Diagnóstico: Supervise las métricas de CPU, memoria, retraso del bucle de eventos y recolección de basura por instancia de aplicación.

Cuellos de botella en redes e infraestructuras

Síntomas: Saturación del ancho de banda, tiempos de espera de conexión, retrasos en el protocolo de enlace SSL bajo carga

Causas comunes:

• Respuestas sin comprimir que consumen ancho de banda
• Activos estáticos servidos desde el servidor de aplicaciones en lugar de CDN
• Terminación SSL/TLS en el servidor de aplicaciones en lugar del balanceador de carga
• Ancho de banda de red insuficiente para el tipo de instancia del servidor

---

Planificación de capacidad

Las pruebas de carga contribuyen a la planificación de la capacidad, determinando cuánta infraestructura necesita para eventos pico.

La fórmula de planificación de capacidad

1. Determine la expectativa de tráfico máximo: utilice los datos del año pasado más las proyecciones de crecimiento. Si esta es su primera venta importante, haga una estimación basada en el alcance de marketing y los puntos de referencia de la industria.
2. Agregue margen de seguridad: planifique 2 o 3 veces el pico esperado para manejar el tráfico viral inesperado
3. Ejecute la prueba de carga a la capacidad objetivo: verifique que su infraestructura maneje entre 2 y 3 veces el pico con tiempos de respuesta aceptables.
4. Calcule el costo: determine el costo de la infraestructura para la capacidad máxima y decida si el escalado automático o el aprovisionamiento previo es más rentable

Lista de verificación previa al escalamiento

Empiece a prepararse entre 8 y 12 semanas antes del evento:

Escalado automático frente a aprovisionamiento previo

El escalado automático ajusta la capacidad en función de las métricas de demanda, pero tarda entre 3 y 10 minutos en agregar nuevas instancias. Para picos repentinos de tráfico (inicio de venta flash, publicación viral en redes sociales), el aprovisionamiento previo evita la demora.

Enfoque recomendado: Aprovisionamiento previo para manejar los picos esperados, configurar el escalado automático para picos inesperados más allá de la capacidad aprovisionada previamente.

---

Análisis posterior a la prueba

La prueba de carga en sí es sólo la mitad del valor. El análisis posterior a la prueba convierte los datos sin procesar en prioridades de optimización procesables.

Métricas clave para analizar

Creando un plan de acción

Priorizar los hallazgos por impacto empresarial:

1. Errores en el pico: cualquier solicitud que devuelva 5xx bajo carga debe corregirse. Estas son ventas perdidas.
2. Rendimiento del proceso de pago: si los tiempos de respuesta del proceso de pago superan los 2 segundos, primero optimice esta ruta. El pago lento afecta directamente la conversión.
3. Rendimiento de búsqueda y navegación: el descubrimiento lento de productos reduce los artículos vistos y el tamaño del carrito.
4. Administración y back-office: pueden degradarse durante el pico sin afectar los ingresos. Resta prioridad si es necesario.

---

Preguntas frecuentes

¿Cómo pruebo la carga de una tienda Shopify si no controlo la infraestructura?

Concéntrate en lo que controlas: tu código de tema personalizado, aplicaciones de terceros e integraciones externas. Utilice herramientas como Lighthouse CI para realizar pruebas de rendimiento del frontend. Pruebe sus puntos finales de procesamiento de webhooks y API de sincronización de inventario bajo carga. Para los comerciantes de Shopify Plus, trabaje con el equipo de éxito comercial de Shopify para revisar la capacidad de su tienda específica.

¿Cuál es la diferencia entre pruebas de carga y pruebas de estrés?

Las pruebas de carga validan que su sistema maneje el tráfico máximo esperado con un rendimiento aceptable. Las pruebas de estrés van más allá de los límites esperados para encontrar el punto de ruptura y verificar una degradación elegante. Prueba de carga para prepararse para eventos conocidos; prueba de estrés para descubrir límites desconocidos y garantizar que el sistema falle de forma segura y no catastrófica.

¿Debo cargar la prueba en producción o en preparación?

Pruebe en un entorno que refleje la producción lo más fielmente posible. Los entornos de prueba suelen tener bases de datos más pequeñas, menos servidores y diferentes configuraciones de red. Si es posible, ejecute pruebas de carga en la infraestructura de producción durante las horas de poco tráfico. Como mínimo, utilice datos del tamaño de producción en su base de datos provisional.

¿Cómo simulo un procesamiento de pagos realista en pruebas de carga?

Utilice modos de pruebas/zona de pruebas del proveedor de pagos que acepten números de tarjetas de prueba. Stripe, PayPal y otros proveedores ofrecen entornos de prueba que procesan transacciones sin cargar tarjetas reales. Pruebe el flujo de pago completo, incluidas las llamadas a la API de pago, para identificar cuellos de botella en la integración. Supervise los límites de tarifas de los proveedores de pagos: algunos proveedores aceleran las solicitudes de sandbox de manera diferente a la producción.

¿Con qué frecuencia debo ejecutar pruebas de carga?

Realice pruebas de carga exhaustivas antes de cualquier evento de tráfico importante (Black Friday, lanzamientos de productos, campañas de marketing). Ejecute pruebas de carga más pequeñas automatizadas semanalmente o después de cambios importantes en el código como parte de CI/CD. Incluya pruebas de carga en su lista de verificación de implementación para detectar cambios que afecten a los puntos finales de alto tráfico.

---

¿Qué sigue?

Comience con una prueba de carga de referencia frente a sus patrones de tráfico de producción actuales. Identifique sus tres principales cuellos de botella y optimícelos antes de ejecutar la siguiente prueba. Repita este ciclo hasta que su plataforma maneje cómodamente entre 2 y 3 veces el tráfico máximo esperado con tiempos de respuesta inferiores a 500 ms.

Para conocer el contexto más amplio de la ingeniería de rendimiento, consulte nuestra guía fundamental sobre ampliar su plataforma empresarial. Para optimizar la infraestructura que soportan sus pruebas de carga, lea nuestra guía sobre escalado de infraestructura y equilibrio de carga.

ECOSIRE proporciona pruebas de carga y optimización del rendimiento para plataformas de comercio electrónico en Shopify y Odoo. Comuníquese con nuestro equipo para la preparación previa al evento.

---

Publicado por ECOSIRE: ayuda a las empresas a escalar con soluciones impulsadas por IA en Odoo ERP, Shopify eCommerce y OpenClaw AI.