Tu tienda en línea sobrevive a las semanas tranquilas de octubre en un plan de hosting diseñado para tráfico ordinario. El Black Friday no pide permiso antes de multiplicar ese tráfico por diez o veinte veces en una sola hora. Las pruebas de carga antes de noviembre muestran dónde cede tu pila: la página de pago, la base de datos, el servidor de imágenes o el plan de hosting en sí. Sáltatelo y lo descubrirás en vivo, frente a clientes que pagan, en el único día en que una página lenta cuesta más. Este artículo cubre qué herramientas funcionan realmente, qué cuestan, en qué orden probar y dónde suelen fallar los sitios de WordPress primero.
Qué le hace realmente el tráfico del Black Friday a un sitio
Un martes normal envía un goteo de visitantes que navegan, añaden un artículo y se van. El Black Friday envía una multitud que aterriza en las mismas cinco páginas de productos minutos después de que salga tu correo electrónico de descuento. El servidor trata cada visita como una solicitud nueva: una consulta de base de datos, un cálculo de carrito, una escritura de sesión. Cada capa de la pila, el servidor web, PHP, la base de datos, la pasarela de pago, tiene un límite.
Cuando la multitud supera ese techo, las páginas se ralentizan y el proceso de pago se agota por tiempo. Algunos de esos visitantes se van sin comprar nada y rara vez vuelven para intentarlo de nuevo más tarde. Las pruebas de carga encuentran el techo en octubre, mientras todavía hay tiempo para elevarlo, en lugar de en noviembre, cuando la única opción es verlo fallar en tiempo real.
Herramientas de prueba de carga y lo que realmente cuestan
Tres herramientas surgen una y otra vez para este trabajo: Apache JMeter, k6 y Gatling. JMeter es gratuito y sigue siendo la respuesta predeterminada en muchos equipos de control de calidad empresariales, pero ejecutarlo bien aún requiere un entorno lo suficientemente parecido al de producción para que sea relevante, generadores de carga que no sean la laptop de alguien y una factura que crece con el tráfico que simulas.
k6, el motor de pruebas de carga de Grafana, resuelve parte de ese problema. El motor k6 es totalmente de código abierto bajo la licencia AGPL-3.0 y gratuito para ejecución local ilimitada, por lo que puedes ejecutar cualquier número de usuarios virtuales en tu propio hardware sin costo alguno. Una sola máquina bien equipada suele poder manejar decenas de miles de usuarios virtuales por sí sola, lo que cubre la mayoría de las tiendas independientes.
El coste aparece una vez que necesitas escala o ubicaciones de prueba distribuidas. Grafana Cloud cobra k6 a $0.150 por hora de usuario virtual después de un nivel gratuito mensual de 500 horas. Toma una prueba moderada: 500 usuarios virtuales durante 30 minutos, ejecutados dos veces por semana. Esa ejecución es de 250 horas de usuario virtual, y el mes suma 2,000 VUh. Haz los números y el plan k6 Pro de Grafana Cloud se sitúa cerca de $244 al mes, el plan de equipo de Artillery Cloud cobra una tarifa plana de $199 independientemente del uso, y el plan de equipo empresarial de Gatling se convierte en aproximadamente $413 al mes, aunque el plan de equipo de Gatling permite solo 5 horas de pruebas al mes.
Escala la prueba hasta algo más cercano a un ensayo real del Black Friday, digamos 10,000 usuarios virtuales durante dos horas, y el precio se mueve con él. Grafana Cloud k6 cotiza a aproximadamente $0.15 por VU-hora en su nivel Pro, lo que equivale a unos $3,000 por 20,000 VU-horas. Esa única ejecución de ensayo puede costar más que un mes de alojamiento, que es por lo que la mayoría de las tiendas prueban seriamente una vez antes de noviembre en lugar de cada semana.
Qué probar primero y en qué orden
Empieza con el flujo de pago, no con la página de inicio. Una página de inicio que carga lentamente molesta a la gente; un pago que falla hace perder la venta por completo, así que se gana la primera prueba. Simula el camino exacto que sigue un comprador: página de producto, añadir al carrito, formulario de dirección, paso de pago, página de confirmación.
Prueba la pasarela de pago por separado y en modo sandbox antes de combinarla con el resto del flujo. Los proveedores de pago limitan las llamadas sandbox mucho más agresivamente que el tráfico en vivo, y una prueba de carga que inunda el sandbox puede activar ese límite y producir fallos falsos que no tienen nada que ver con tu propio servidor. Ejecuta la prueba combinada completa dos o tres semanas antes del Black Friday, no la semana anterior, para que haya tiempo de arreglar lo que la prueba encuentre y volver a ejecutarla.
Aumenta el tráfico simulado rápido en lugar de gradualmente. El tráfico real del Black Friday llega en ráfagas, provocado por un envío de correo electrónico o una publicación en redes sociales, no por una subida lenta durante una hora. Una prueba que aumenta suavemente oculta el modo de fallo exacto que intentas detectar.
Donde los sitios de WordPress se rompen realmente
La mayoría de los fallos de WordPress se deben a uno de tres límites, y ninguno de ellos aparece hasta que llega el pico de tráfico. PHP-FPM, el gestor de procesos que ejecuta PHP en la mayoría de los planes de alojamiento, limita el número de solicitudes simultáneas que gestionará a la vez. Los planes de alojamiento compartido económicos y los VPS pequeños a menudo fijan ese límite en un solo dígito, lo que significa que el décimo visitante que llega al sitio en el mismo segundo simplemente espera o agota su tiempo de espera.
La base de datos cuenta una historia similar. MySQL y MariaDB limitan el número de conexiones abiertas, y una instalación de WordPress cargada de plugins puede agotar ese límite solo con el tráfico normal, antes de que aparezca un solo visitante impulsado por descuentos. Los plugins de caché y los CDN ayudan enormemente, pero solo para las páginas que pueden cachear. Un banner de venta con un temporizador de cuenta regresiva en vivo, un contador de existencias en una página de producto o un mensaje personalizado de "artículos restantes" pueden forzar a una página de vuelta al modo de consulta de base de datos completa sin caché en el momento exacto en que el tráfico alcanza su punto máximo.
Qué arreglar primero y qué puede esperar
Arregla el flujo de pago y compra antes que nada. Ese es el paso donde una falla cuesta dinero directamente, y también es el paso donde la mayoría de las pruebas de carga revelan problemas primero. Aumenta los límites de trabajadores PHP-FPM y los límites de conexión de base de datos a continuación, ya que ambos suelen ser un cambio de configuración de una sola línea en lugar de una migración.
Los elementos dinámicos como los contadores de existencias en vivo y los temporizadores de cuenta regresiva pueden esperar, o ser intercambiados por una versión en caché más simple para el período de oferta. Una insignia simple de "casi agotado" que se actualiza cada pocos minutos cuesta mucha menos capacidad del servidor que un contador en vivo, y los compradores rara vez notan la diferencia. Ejecuta una prueba de carga real en octubre, corrige lo que encuentre, luego ejecútala de nuevo dos semanas después para confirmar que la corrección se mantuvo.
