Casi todos los sistemas tienen un día al año que lo decide todo. Para una tienda de PrestaShop es el Black Friday o el primer día de rebajas; para la sede electrónica de un ayuntamiento, la mañana en que se abre el plazo de las ayudas o de las plazas de la escuela de verano; para una academia online, la semana de matrícula. El resto del año el servidor va sobrado, y por eso nadie sospecha nada. Las pruebas de carga reproducen ese día con antelación, sobre una copia del sistema, y le dicen cuántos usuarios aguanta, qué pieza cede primero y cuánto cuesta ganar margen. Generamos el tráfico desde la nube y en remoto, sin instalar agentes en sus servidores.
No se trata de lanzar millones de peticiones a ver qué pasa. Cada prueba responde a una pregunta concreta de negocio y se diseña con sus datos de tráfico y los registros del servidor.
Reproducimos lo que hacen las personas: navegar por categorías, usar el buscador, añadir al carrito, registrarse, pagar con tarjeta o Bizum, descargar un justificante. Las proporciones entre acciones salen de Google Analytics, Matomo o los logs, no de una estimación a ojo.
Subimos usuarios por escalones y anotamos en qué punto el tiempo de respuesta pasa de aceptable a molesto y en cuál empiezan los errores. Esos dos números son los que le interesan a la dirección.
Llevamos el sistema más allá de su límite y simulamos la avalancha de los primeros minutos tras un envío de newsletter o una notificación push. Importa tanto cómo cae como cuándo cae: con un mensaje de espera amable o con una página en blanco.
Tráfico sostenido durante horas para detectar lo que solo aparece con el tiempo: memoria que no se libera, colas que crecen, sesiones que se acumulan, discos que se llenan de registros.
Revisamos las consultas más lentas, los índices que faltan y las páginas que se generan una y otra vez sin necesidad. En PrestaShop y WooCommerce, los listados con filtros y el buscador suelen ser los primeros sospechosos.
La pasarela de pago, el cálculo de portes del transportista o el servicio de correo transaccional tienen sus propios límites. Pedimos permiso a cada proveedor o los sustituimos por simuladores durante la prueba, y lo dejamos anotado en el informe.
Resultados con gráficas comprensibles, cuellos de botella priorizados y el efecto esperado de cada cambio. Ampliar el servidor figura en el plan solo cuando de verdad compensa frente a arreglar el código o la configuración.
La preparación de escenarios suele ocupar unos días laborables; cada ronda de pruebas dura pocas horas. Conviene empezar varias semanas antes de la fecha crítica para tener margen de aplicar mejoras.
Por ejemplo: «2.000 usuarios simultáneos con respuesta por debajo de 2 segundos en ficha de producto y carrito». Sin objetivo numérico no hay resultado que evaluar.
Copia del sistema con un volumen de datos parecido al real y acuerdo de ventana con su proveedor de hosting o de nube.
Ejecución por escalones mientras su equipo o el nuestro vigila la monitorización de los servidores en tiempo real.
Aplicación de los cambios más rentables y nueva ronda para medir cuánto se ha ganado de verdad.
Un servidor más grande no arregla una consulta mal escrita. Es habitual que una pyme duplique la cuota de hosting antes de una campaña y que la web se caiga igual, porque el problema era un listado sin caché que lanzaba doscientas consultas por visita. Medir primero y gastar después sale casi siempre más barato.
Probablemente no, y precisamente por eso hay que saberlo. En un alojamiento compartido no se puede probar sin permiso del proveedor, porque afecta a otros clientes. En ese caso montamos una copia temporal en un VPS equivalente o en la nube, en un centro de datos en España o en la UE, y la eliminamos al terminar.
Acceso a la analítica o a los logs para diseñar los escenarios, una copia del sistema o permiso para montarla, usuarios de prueba y una persona técnica disponible durante las rondas. Si la tienda cobra con Redsys, también el acceso al entorno de pruebas del TPV.
Solo como excepción, de madrugada, con límite de tráfico y ventana firmada. Lo normal es trabajar sobre una copia para no afectar a clientes reales ni ensuciar las estadísticas de ventas.
Siempre. Muchas peticiones desde pocas direcciones se parecen a un ataque, y los sistemas de protección de Arsys, IONOS, OVHcloud o Cloudflare pueden cortar la prueba a mitad. Le ayudamos a redactar el aviso y a cuadrar la fecha.
Díganos qué fecha le preocupa y cuánta gente espera. Le proponemos escenarios y un calendario para llegar con margen.
Hemos recibido su solicitud
Tendrá respuesta en un día laborable. Si nos avisa de una avería que tiene parado a su equipo, la tratamos con prioridad.
No encontramos esa ciudad. Revise cómo está escrita o elija la capital de provincia más cercana: como trabajamos en remoto, el servicio es el mismo en cualquier punto de España.
