El mayor error que cometen los equipos en las pruebas de carga ocurre antes de que se escriba un solo script: eligen el tamaño de prueba equivocado. Una prueba de carga demasiado pequeña le da una confianza falsa. Todo se ve en verde en sus paneles, pero cuando el tráfico se dispara en producción, aparecen las grietas. Una prueba de carga demasiado grande es igual de mala. Desperdicia tiempo, dinero e infraestructura probando un escenario que nunca ocurre, y termina persiguiendo cuellos de botella fantasma.
Hay muchas historias aleccionadoras. Por ejemplo, una empresa empresarial lanzó un nuevo producto en Black Friday después de probar solo con 500 usuarios concurrentes porque eso “parecía seguro”. En minutos tras la promoción en vivo, el tráfico se disparó a 2.500 usuarios y la canalización de pago colapsó. En el otro extremo del espectro, una universidad insistió en probar su nuevo portal con 1.000 usuarios, aunque el tráfico histórico pico nunca había superado los 5.000. El resultado: facturas infladas en la nube y un mes perdido persiguiendo cuellos de botella que nunca se habrían desencadenado en la realidad.
Dimensionar es donde el arte y la ciencia de las pruebas de carga se encuentran. Necesita un número que sea lo suficientemente grande para ser significativo, pero lo bastante fundamentado para reflejar la realidad. El problema es que la mayoría de los equipos no tienen una cifra limpia de “usuarios concurrentes” en sus documentos de proyecto. Muchos optan por un número redondo como 500, 1.000 o 10.000 simplemente porque parece autoritario en una diapositiva, y eso no es suficiente.
En este artículo, repasaremos tres maneras probadas para dimensionar sus pruebas de carga: 1) impulsado por requisitos, 2) basado en transacciones y 3) basado en analíticas. Cada uno le da un marco para convertir datos desordenados o incompletos en un tamaño de prueba defendible: uno que coincida con el tráfico de producción en vez de con conjeturas.
Método 1: Dimensionamiento impulsado por requisitos
Cuando tiene suerte, sus requisitos ya contienen la respuesta: solo tiene que leer entre líneas.
Algunos escenarios lo hacen obvio. Si su empresa planea una asamblea transmitida en vivo donde la asistencia es obligatoria, la concurrencia equivale al número de asistentes. Si hay 1.000 empleados, debería probar para 1.100 usuarios concurrentes (el número de asistentes más un 10% de margen de seguridad). Eso es lo más directo que puede ser.
Otros eventos son más delicados pero aún previsibles. Tome un sistema de inscripción a cursos universitarios. Durante la mayor parte del año, el tráfico es constante y modesto. Pero el día de matrícula, el sistema sufre. Los estudiantes corren para conseguir plazas en los cursos populares, y el tráfico se dispara muy por encima de la línea base. Si sabe que hay 10.000 estudiantes y la experiencia le dice que el 90% de ellos accederán al sistema durante la matrícula, eso son 9.000 usuarios concurrentes. Sume comportamientos como estudiantes que piden a amigos o familiares que inicien sesión desde varios dispositivos, y la concurrencia real puede superar el 100% de la población estudiantil. Una prueba segura podría dimensionar el tráfico al 200% de los usuarios estudiantiles.
Esto también ocurre en otras industrias. Considere un portal de impuestos gubernamental en abril. El sistema puede tener un uso ligero durante todo el año, pero en el día de presentación, la concurrencia se dispara de forma dramática. O mire una plataforma de venta de entradas para conciertos. Para la mayoría de los eventos, el tráfico se reparte. Pero cuando las entradas de un artista importante salen a la venta a las 10:00 en punto, todos los fans actualizan la página al mismo tiempo (por no mencionar a los bots que intentan comprar entradas, lo cual es otra cuestión a tener en cuenta). Esos son momentos impulsados por requisitos, y su prueba de carga debe dimensionarse en consecuencia.
Problemas: Los requisitos a menudo subestiman. Las partes interesadas pueden dar cifras bajas para ser conservadoras en el presupuesto, o pueden no contar con los “observadores” que inician sesión antes para asegurar plaza, o con bots. Cuestione siempre el número, modele el comportamiento de oleadas y añada márgenes.
Regla general: El dimensionamiento impulsado por requisitos funciona mejor cuando el evento es limitado en el tiempo y predecible, con recuentos de participantes claros. En esos casos, los requisitos le dan la línea base más defendible.
Método 2: Dimensionamiento basado en transacciones
Cuando los requisitos no le dan un número, sus transacciones de negocio lo harán. En vez de pensar en términos de usuarios abstractos, piense en términos de acciones: pedidos, registros, pagos, cargas, pujas.
Las matemáticas funcionan así:
- Identifique el volumen máximo de transacciones. Suponga que su plataforma de comercio electrónico procesa 1.000 pedidos en un día típico, pero durante las fiestas el volumen sube un 50% a 1.500 pedidos.
- Encuentre la ventana activa. Si la mayoría de los pedidos ocurren entre las 10:00 y las 22:00, esa es una ventana de 12 horas, o ~125 pedidos por hora.
- Ajuste por distribución desigual. El tráfico rara vez es uniforme. Si las horas pico son un 25% más altas, eso son ~160 pedidos en la hora más concurrida.
- Tradúzcalo en concurrencia. Si a un cliente le toma cinco minutos completar un pedido, entonces 160 pedidos/hora equivalen a 2,67 pedidos/minuto. Multiplique por la duración de cinco minutos y obtiene ~14 usuarios concurrentes que realmente realizan pedidos.
- Añada tráfico de navegación. Los compradores no son toda la historia. Si sus analíticas muestran 10 navegadores por cada comprador, eso son otros 140 usuarios concurrentes.
- Añada un margen. Con un 25% de margen de seguridad, ahora está en ~190 usuarios. Incluso podría querer añadir un 50% o 100% (o más dependiendo de la variabilidad).
Ese es el tamaño de prueba en este ejemplo: 190 usuarios concurrentes que reproducen los patrones de transacción más ocupados y significativos que su sistema verá.
Este método funciona bien porque relaciona la carga directamente con los resultados de negocio. No solo está probando “190 usuarios”, está validando la capacidad de procesar “160 pedidos pico/hora más navegación”. Es un número que las partes interesadas entienden y valoran.
Segundo ejemplo: Plataformas de subastas. Suponga que ve un promedio de 10.000 pujas por día, con un 40% de esas concentradas en las dos últimas horas de subastas de alto perfil. Eso son 4.000 pujas en dos horas, o ~2.000/hora. Si la puja media tarda 30 segundos en realizarse, eso son ~16 usuarios concurrentes pujando. Pero si su proporción de navegación a puja es 30:1 (común en sitios de subastas), necesitará simular casi 500 usuarios para reflejar la carga real. Ese tamaño de prueba le dice si su sistema puede manejar no solo el pico de pujas, sino la avalancha de navegadores que observan y actualizan listados.
La estacionalidad también importa. El comercio minorista no es el único vertical con picos. Las plataformas de viajes ven aumentos durante las vacaciones de primavera y festivos. Los portales fiscales se colapsan en abril. Las incorporaciones a SaaS se disparan cuando se cierran nuevos contratos. El dimensionamiento basado en transacciones se adapta a todo esto al vincular la concurrencia a eventos específicos del negocio.
Regla general: Use el dimensionamiento basado en transacciones cuando los requisitos sean vagos pero las métricas de negocio estén claras. Es preciso, comprensible para las partes interesadas y se traduce directamente en resultados.
Método 3: Dimensionamiento basado en analíticas
Cuando los requisitos son vagos y no tiene datos de transacciones, las herramientas de analíticas pueden llenar el vacío. Google Analytics, Adobe Analytics u otras plataformas le dan datos de tráfico que pueden traducirse en concurrencia con un poco de cálculo.
He aquí cómo:
- Empiece con el tráfico pico. Suponga que su sitio vio 50.000 visitantes en su día más concurrido.
- Convierta a tráfico horario. Divida por 24 horas = ~2.100 visitantes/hora.
- Ajuste por picos. El tráfico no es plano. Añada un 50% para tener en cuenta la distribución desigual → ~3.150 visitantes/hora.
- Use la duración media de la sesión. Si los usuarios pasan de media dos minutos en el sitio, entonces 3.150 / 60 × 2 = ~105 usuarios concurrentes.
- Añada margen. Con un 25% de margen, está en ~130 usuarios concurrentes.
Ese es su tamaño de prueba: 130 usuarios que reflejan el tráfico más intenso que han visto sus analíticas.
Ejemplo: Una empresa SaaS con 500.000 usuarios activos mensuales. Si los usuarios activos diarios son ~10% de ese número (50.000), y el 20% inicia sesión durante las horas pico laborales, tiene 10.000 usuarios en la ventana más concurrida. Si la duración media de sesión es de 15 minutos, eso se traduce en ~2.500 usuarios concurrentes para probar.
Advertencias de precisión: Las analíticas son mejores que nada, pero no son perfectas. Considere:
- Bloqueadores de anuncios que pueden ocultar algunas visitas.
- Banners de consentimiento de cookies que pueden causar subconteo si los usuarios optan por no ser rastreados.
- Tráfico de bots que puede inflar los números si no está filtrado.
A pesar de esos problemas, las analíticas son un recurso práctico. Reflejan sesiones de usuario reales, normalizadas entre dispositivos y ubicaciones, y pueden segmentarse por geografía o tipo de dispositivo si su plataforma tiene tráfico regional o centrado en móviles.
Regla general: Use el dimensionamiento basado en analíticas cuando no haya métricas de negocio disponibles, pero sí datos de tráfico consistentes. Es la forma más práctica de fundamentar las pruebas en la realidad.
Caso especial: aplicaciones completamente nuevas
¿Y si está empezando con una aplicación completamente nueva? No tiene requisitos que definan concurrencia, historial de transacciones ni datos analíticos, lo cual es un problema totalmente distinto.
El error común es elegir un número redondo como “2.000 usuarios concurrentes” porque parece seguro. Pero ese número no tiene sentido si no está ligado al comportamiento esperado.
Un enfoque mejor es proyectar el tráfico en términos de transacciones o sesiones. Si espera 200 cargas por hora, dimensione su prueba para validar eso. Si espera 10.000 registros el día del lanzamiento, conviértalos en tráfico horario y duración de sesión. Incluso estimaciones toscas enmarcadas así le dan resultados que pueden interpretarse en términos de negocio: son matemáticas que puede modelar o calcular.
Ejemplo: Suponga que su equipo de marketing proyecta 5.000 registros durante la semana de lanzamiento, concentrados por un gran comunicado de prensa. Si asume que el 60% cae el primer día, eso son 3.000 registros. Distribuido de forma desigual, con el 40% en las primeras tres horas, son ~1.200 registros. Si la creación de cuenta toma tres minutos, está mirando ~60 registros concurrentes. Añada navegación y tráfico de reintentos, y razonablemente podría probar entre 200–300 usuarios concurrentes. Ese número está enraizado en suposiciones, pero al menos son explícitas y puede refinarlas cuando lleguen datos reales.
Tenga cuidado con las conjeturas porque los gerentes quieren presentar algo de cierta manera. Las partes interesadas pueden presionar por números enormes (“Probemos 50.000 usuarios para mostrar a los inversores que estamos listos para escalar”). Resista eso. Las pruebas sobredimensionadas no generan confianza: crean ruido y desperdicio. Fundamente su dimensionamiento en transacciones proyectadas, aunque sean estimaciones.
Tabla resumen: elegir el método correcto
| Método | Cuándo usarlo | Fortalezas | Riesgos/Desventajas |
| Impulsado por requisitos | Eventos predecibles y limitados en el tiempo | Claro, defendible, fácil de calcular | Subestimaciones por parte de stakeholders, conflictos |
| Basado en transacciones | Aplicaciones existentes con datos de negocio claros | Vincula directamente a resultados, proporciones precisas | Requiere buenas métricas, efectos estacionales |
| Basado en analíticas | Sitios con historial de tráfico consistente | Fácil de calcular, basado en sesiones reales | Bloqueadores, bots, precisión desigual |
| Nuevas aplicaciones | Sin historial o datos disponibles | Obliga a hacer suposiciones explícitas, a prueba de futuro | Riesgo de conjeturas |
Reflexiones finales sobre cómo dimensionar correctamente las pruebas de carga
El propósito de la prueba de carga no es alcanzar un número: es responder a una pregunta. ¿Puede su sistema manejar los comportamientos y eventos específicos que importan a su negocio?
- Si los requisitos le dan números directos, úselos.
- Si no, las transacciones proporcionan el anclaje más exacto y orientado al negocio.
- Si esos no están disponibles, las analíticas ofrecen una alternativa fiable.
- Para sistemas nuevos, las proyecciones son mejores que las conjeturas arbitrarias.
Y sin importar el método que use, siempre añada un margen. El tráfico real es puntilloso, impredecible y rara vez se alinea con promedios perfectos.
LoadView ayuda a hacer prácticos cada uno de estos métodos de dimensionamiento. Con LoadView, puede modelar no solo recuentos de usuarios, sino patrones realistas: tráfico en ráfagas durante la matrícula, mezcla de navegación y pedidos, o distribución global que coincida con sus analíticas. Eso significa que su prueba no es solo un número, es un ensayo para la realidad de producción.
Dimensionar es la primera decisión en cualquier prueba de carga. Hágalo bien, y cada resultado que obtenga después tendrá sentido. Hágalo mal, y ningún guion ni informe lo salvarán. Con los tres métodos descritos aquí, puede dimensionar sus pruebas con confianza y asegurarse de que sus resultados de rendimiento realmente coincidan con el tráfico y la actividad en su sitio o aplicación.