Los números redondos son fáciles de acordar y casi no te dicen nada. El tráfico real llega en ráfagas, se divide de manera desigual entre funciones y cambia su mezcla en el momento exacto en que el volumen alcanza su pico. Una prueba que envía una pared plana de solicitudes idénticas ejercita un camino de código diferente al de producción, con comportamientos de caché, planes de consultas y contención de bloqueos que no tienen relación con el sistema en vivo.
Aquí te mostramos cómo construir un modelo de tráfico a partir de datos que ya recopilas, y cómo ejecutarlo para que los resultados tengan sentido.
Tabla de Contenidos
- Qué hace que el tráfico empresarial sea difícil de falsificar
- Dónde ya viven los datos de tráfico
- Cómo construir un modelo de tráfico a partir de datos de producción
- Dónde fallan los modelos de tráfico
- Cómo se ven las formas del tráfico empresarial real
- Cómo ejecutar el modelo en LoadView
- Cómo verificar el modelo contra producción
- Conclusión
- Preguntas frecuentes
Qué hace que el tráfico empresarial sea difícil de falsificar
Tres cosas complican a los equipos que van directamente de un número de cuenta a una prueba en ejecución.
La concurrencia y la tasa de llegada no son el mismo número. Cuando un interesado dice “necesitamos manejar 5,000 usuarios,” pregunta a cuál se refiere. Cinco mil personas conectadas simultáneamente es una prueba completamente diferente a cinco mil sesiones iniciando cada hora. Si lo interpretas mal en la dirección generosa, pasarás semanas ajustando para una carga que nunca llegará. Si te equivocas en la otra dirección, la prueba no te dice nada. La prueba de usuarios concurrentes solo significa algo una vez que sabes cuál de los dos números estás apuntando. Esta es la división entre un modelo basado en tasa de llegada, que refleja cómo los usuarios realmente llegan, y un modelo basado en concurrencia, que mantiene una población fija en el sistema. El tráfico público casi siempre es el primero. Los sistemas con una base de usuarios limitada—escritorios de centros de llamadas, asientos licenciados, portales de agentes—realmente se comportan como el segundo.
El tráfico tiene una forma, y la forma es lo que causa el daño. Los pools de conexión, los grupos de autoescalado y los servidores de aplicaciones calentados Just-in-Time responden a la tasa de cambio, no solo al límite máximo. Un sistema que maneja cómodamente 2,000 usuarios concurrentes puede fallar en el camino hacia los 2,000 si llega en noventa segundos.
La mezcla de transacciones se mueve con el volumen. A volumen promedio, un sitio de comercio electrónico ve principalmente navegación. Durante una venta flash, las llamadas de pago e inventario ocupan una parte mucho mayor del mismo conteo de solicitudes. El número total parece idéntico en un tablero de control. La carga en la base de datos no lo es.
Un conteo plano de usuarios virtuales y una curva de llegada moldeada pueden producir el mismo rendimiento promedio mientras estresan partes completamente diferentes de la pila.
Dónde ya viven los datos de tráfico
No necesitas una nueva instrumentación. La mayoría de esto ya se está escribiendo en disco en algún lugar. El trabajo es unirlo en sesiones y filtrar el tráfico bot antes de contar cualquier cosa.
Fuente
Qué se extrae de ella
Fuente
Registros de acceso del servidor web y balanceador de carga
Qué se extrae de ella
Solicitudes por segundo por endpoint, distribución de códigos de estado, la marca de tiempo real de tu hora más ocupada
Fuente
APM o monitoreo de usuario real (Dynatrace, Datadog, New Relic)
Qué se extrae de ella
Duración de sesión, tiempo entre páginas, tiempo real entre interacciones
Fuente
Análisis web (exportaciones GA4, Adobe Analytics)
Qué se extrae de ella
Sesiones por hora, división por dispositivo y navegador, geografía, páginas de entrada
Fuente
Registros CDN (CloudFront, Fastly, Akamai)
Qué se extrae de ella
Tasa de aciertos de caché, tasa de descarga del origen, qué activos fallan
Fuente
Registros de proveedor de identidad o SSO (Okta, Entra ID)
Qué se extrae de ella
Tasa de inicio de sesión y concurrencia de sesiones, que a menudo es la única señal usable para aplicaciones internas
Fuente
Programador de lotes y base de datos
Qué se extrae de ella
Qué más está corriendo durante tu ventana pico
Las aplicaciones empresariales internas usualmente no tienen etiquetas de análisis. Los registros de autenticación y los registros del servidor de aplicaciones cubren la brecha: los eventos de inicio de sesión te dan la tasa de llegada, y el tiempo entre la primera y última solicitud por sesión te da la duración.
Cómo construir un modelo de tráfico a partir de datos de producción
Cuatro salidas definen el modelo: tasa de llegada, mezcla de transacciones, distribución del tiempo de reflexión y división geográfica.
Paso 1: Elige la ventana exacta que estás modelando
No “tráfico pico.” Una hora específica, en una fecha específica, extraída de tus registros. Toma la hora de mayor rendimiento de los últimos doce meses, luego elige una segunda ventana que cubra tu peor evento comercial: cierre de fin de mes, inscripción abierta, Black Friday, reporte trimestral. Modela ambas. Casi nunca tienen la misma forma.
Paso 2: Cuenta sesiones, no solicitudes
Las solicitudes por segundo son el número más fácil de extraer y el menos estable. Envíes una actualización frontend que agrupe tres llamadas API en una y tu conteo de solicitudes cae un tercio sin cambio en la demanda. Las sesiones por hora reflejan lo que los usuarios realmente están haciendo. La diferencia es mayor en aplicaciones de página única, donde un clic puede generar una docena de llamadas API en segundo plano.
Extrae sesiones por hora para tu ventana, más la duración media y del percentil 90 de la sesión. Mantén ambos números: la cola importa en el paso tres.
Paso 3: Convierte sesiones en concurrencia
La Ley de Little conecta la tasa de llegada con la concurrencia:
Sesiones concurrentes = sesiones por hora × (minutos promedio por sesión ÷ 60)
18,000 sesiones/hora × (6 minutos ÷ 60) = 1,800 sesiones concurrentes
Ejecutar 18,000 usuarios virtuales concurrentes contra esa aplicación implica que has probado algo diez veces mayor que tu pico real. Fallarás una prueba que hubieras pasado, luego pasarás un sprint persiguiendo un cuello de botella que producción nunca alcanzaría.
La Ley de Little toma la media, así que trata el P90 como una verificación de dimensionamiento separada en lugar de una segunda lectura de la fórmula. Alimenta un P90 de 22 minutos contra esa media de 6 minutos y obtienes aproximadamente 6,600—la concurrencia que tendrías si cada sesión durara tanto como el décimo más lento. Deliberadamente pesimista, y el número útil para planificación de capacidad cuando las sesiones largas ocupan recursos escasos como hilos de reportes o conexiones de base de datos.
Paso 4: Divide el tráfico en transacciones comerciales
Agrupa los endpoints en transacciones comerciales en lugar de URLs: buscar, ver detalle, añadir al carrito, enviar reclamo, exportar reporte, ejecutar nómina. Luego registra dos mezclas: la participación de cada transacción en el tráfico durante toda la ventana y la participación durante el minuto más ocupado.
Si esas dos mezclas difieren más del porcentaje en alguna transacción, incluye ambas en la prueba y ejecútalas como escenarios separados. Una prueba basada solo en la mezcla horaria subestimará la carga en la transacción que más se dispara en el pico.
Paso 5: Extrae el tiempo de reflexión de sesiones reales
No adivines el tiempo de reflexión ni uses un valor constante. Una pausa fija de cinco segundos sincroniza a todos los usuarios virtuales en una columna que golpea la aplicación en bloque, produciendo un rendimiento irregular que ninguna población real genera.
Extrae el intervalo entre cargas consecutivas de página dentro de sesiones reales desde datos RUM o APM y réprodúcelo como una distribución. Los usuarios empresariales tienden a ser bimodales: intervalos cortos mientras navegan por un flujo que conocen bien y largos mientras leen un documento o atienden una llamada.
Paso 6: Ajusta la rampa a la curva real
Gráfica el conteo de sesiones por minuto a lo largo de tu ventana y da forma a la rampa para que coincida. Tres formas cubren la mayoría de las aplicaciones empresariales:
- Casi vertical. Lanzamientos de producto, venta de boletos y apertura de mercado. La concurrencia máxima llega en menos de dos minutos.
- Escalonada. Aplicaciones internas que se activan a las 9 a.m. en cada zona horaria, un escalón por región.
- Onda cuadrada. Tráfico batch e integración. Encendido a volumen completo, apagado a volumen completo, sin rampa.
Paso 7: Coloca la carga donde están tus usuarios
Toma la división geográfica de analíticas o registros CDN y genera carga desde esas mismas regiones. Esto no es solo para medir latencia para usuarios remotos. La latencia influye en la concurrencia: una sesión abierta por un viaje de ida y vuelta de 280 ms dura más que la misma sesión en un enlace de 20 ms, por lo que tasas de llegada idénticas producen mayor concurrencia. Probar todo desde una sola región oculta esto completamente.
Dónde fallan los modelos de tráfico
Un conjunto de datos para cada usuario virtual. Mismo inicio de sesión, mismo ID de producto, mismo número de cuenta para diez mil usuarios, y tu tasa de aciertos de caché llega casi al 100%. La producción no se comporta así. Parametriza con un conjunto de datos suficientemente amplio para que coincida con la cardinalidad real—a un grupo de cuentas, una lista de SKUs, pedidos únicos por ejecución—luego compara la tasa de aciertos de caché de la prueba contra la producción antes de confiar en cualquier resultado.
Nada más corriendo durante el pico. Los picos empresariales coinciden con trabajos programados: ETL nocturno, reconstrucción de índices, generación de reportes, ventanas de backup, sincronización de replicación. Si el trabajo de conciliación corre a las 2 a.m. y tu pico batch también es a las 2 a.m., un ambiente de prueba limpio sin carga de fondo mide un sistema que no operas.
Pruebas solo por protocolo en aplicaciones con mucho navegador. Una prueba a nivel HTTP repite las solicitudes capturadas al momento de registro. No ejecuta JavaScript, no dispara llamadas cargadas perezosamente, no corre etiquetas de terceros ni renderiza nada. Para una aplicación de página única o portal interno pesado, eso excluye la mayor parte del trabajo que el cliente realmente hace—y todo lo que determina lo que el usuario ve. Las pruebas de carga de aplicaciones web en navegadores reales son la única manera de medir el renderizado del lado cliente bajo carga.
Solo el camino feliz. El tráfico real incluye carritos abandonados, bucles con el botón atrás, inicios de sesión fallidos, tokens expirados y doble clics impacientes. Los inicios de sesión fallidos merecen un escenario propio: golpean al proveedor de identidad, usualmente evitan la caché y a menudo activan la lógica de bloqueo que agrega escrituras.
Cómo se ven las formas del tráfico empresarial real
Tres patrones que aparecen constantemente, y lo que cada uno requiere del modelo.
Venta flash minorista o lanzamiento de producto
La llegada es casi vertical y la mezcla colapsa en tres transacciones: detalle del producto, añadir al carrito, pago. Si la página del producto es cacheable, la tasa de aciertos en CDN mejora porque todos solicitan el mismo ítem caliente, lo que hace que una prueba ingenua parezca fácil. La presión recae en las llamadas no cacheables—revisión de inventario, escrituras en el carrito, autorización de pago—todas golpeando el origen al mismo tiempo con contención a nivel de fila en un solo SKU. Modela la mezcla en el minuto pico, no en la hora.
Cierre de fin de mes en un ERP interno
El volumen de sesiones no es notable. La duración de las sesiones sí. Exportaciones de reportes y publicaciones batch duran minutos, por lo que la concurrencia sube aunque la tasa de llegada parezca estable—la Ley de Little trabajando en tu contra. También se superpone al batch de cierre contable, así que la carga de fondo es parte de la prueba. Divide a los usuarios de reportes y publicaciones de larga duración en su propia clase de transacción con su propia duración en lugar de integrarlos en un promedio único.
Inscripción abierta en seguros
Semanas de carga elevada con un pico fuerte en los últimos dos días. Las sesiones son largas porque las personas leen los documentos del plan, y son pesadas en autenticación y descargas. La porción de varias semanas es una prueba de resistencia, donde las fugas de memoria, el agotamiento del pool de conexiones y el volumen de registros importan más que la concurrencia pico. El pico de los últimos días necesita un modelo propio.
Cómo ejecutar el modelo en LoadView
Una vez que el modelo existe, la configuración de la prueba se deriva de él. LoadView ofrece tres curvas de carga, y tu modelo te indica cuál elegir:
Curva de carga
Úsala cuando tu modelo indique
Curva de carga
Curva de paso de carga
Úsala cuando tu modelo indique
Tienes una cifra objetivo de concurrencia y quieres ver dónde se degrada el tiempo de respuesta al ir subiendo
Curva de carga
Curva basada en objetivos
Úsala cuando tu modelo indique
Tu modelo se expresa como rendimiento—transacciones o sesiones por intervalo—o estás validando un SLA
Curva de carga
Curva ajustable dinámica
Úsala cuando tu modelo indique
Quieres mover la carga y la distribución regional durante la ejecución para encontrar dónde se dobla el sistema
Graba el flujo de la sesión con el EveryStep Web Recorder para que el script camine la misma ruta que un usuario, en un navegador real, a través de los navegadores de escritorio y móviles que muestran tus analíticas. Configura la división regional usando la red de inyección de carga distribuida geográficamente para que coincida con el paso siete de tu modelo.
Para aplicaciones que nunca tocan Internet público, los inyectores on-premises prueban la carga detrás de tu firewall mientras reportan en la misma plataforma—que es cómo se modela la mayoría del tráfico interno de ERP y portales.
Cómo verificar el modelo contra producción
Un modelo de tráfico es una hipótesis hasta que comparas su salida con la realidad. Captura el back end mientras se ejecuta la prueba—eventos de espera en base de datos, saturación del pool de conexiones, profundidad de colas, actividad de autoescalado, tasa de obtención de origen CDN, limitación del proveedor de identidad. Esas señales explican los números a continuación.
Después de la ejecución, pon cinco mediciones lado a lado con producción para la misma ventana:
- Rendimiento por transacción. Si el rendimiento de la prueba está muy por debajo de producción con el mismo número de usuarios, el tiempo de reflexión es demasiado largo o el script está faltando llamadas.
- Porcentajes de mezcla de transacciones. Cambios aquí significan que la lógica de ramificación del script no coincide con cómo se mueven los usuarios.
- Tasa de aciertos en caché. Una prueba al 95% contra producción al 70% significa que el conjunto de datos es demasiado limitado.
- Tasa y tipos de error. La producción casi siempre tiene una tasa base de errores. Una prueba que muestra cero errores usualmente omite algo.
- Duración promedio de la sesión. Esto valida todo el cálculo de concurrencia del paso tres.
Luego analiza tus resultados de prueba de carga contra esos cinco, ajusta el script y vuelve a ejecutar. Dos iteraciones suelen acercar el modelo lo suficiente para confiar en él.
Preguntas frecuentes
¿Cuántos usuarios virtuales necesito realmente?
Calcula a partir de sesiones por hora y duración promedio de la sesión en lugar de elegir un número redondo. Un sistema que maneja 18,000 sesiones por hora con una duración promedio de seis minutos lleva aproximadamente 1,800 sesiones concurrentes, no 18,000. Ejecuta la misma fórmula con la duración P90 de la sesión para una verificación de tamaño pesimista que usar en planificación de capacidad.
¿Puedo simplemente reproducir el tráfico de producción en lugar de modelarlo?
La reproducción es útil para validar un modelo que ya construiste. Por sí sola tiene límites estrictos: el tráfico grabado contiene datos personales que debes limpiar, tokens de sesión que expiran y escrituras con estado que no puedes repetir de forma segura. Y no puede exceder el volumen grabado, que es precisamente el volumen que más necesitas probar más allá.
¿Con qué frecuencia debe reconstruirse el modelo de tráfico?
Después de cualquier lanzamiento que cambie el frontend o el flujo de usuario, después de un cambio comercial que altere la mezcla de transacciones, y antes de cualquier evento de alta carga conocido. Trimestral es un piso razonable para una aplicación estable.
¿Debería ejecutar pruebas a nivel de protocolo o pruebas en navegadores reales?
Responden a preguntas diferentes. Las pruebas a nivel de protocolo son baratas por usuario virtual y buenas para empujar la capacidad del backend y API. Las pruebas en navegadores reales ejecutan JavaScript, disparan llamadas perezosas y corren etiquetas de terceros, que es la única forma de ver qué experimenta un usuario en una aplicación de página única bajo carga. La mayoría de programas empresariales ejecutan ambos.
¿Qué pasa si mi aplicación interna no tiene datos de análisis?
Usa registros de autenticación para la tasa de inicio de sesión y duración de sesión, registros de servidor de aplicaciones para volumen de solicitudes por endpoint, y el programador batch para qué más corre durante tu ventana pico. Las aplicaciones internas rara vez tienen etiquetas de análisis, pero siempre tienen registros de autenticación y servidor.
Conclusión
Un patrón de tráfico realista son cuatro mediciones, no un solo número: qué tan rápido llegan las sesiones, qué hacen esas sesiones, cuánto tiempo pausan los usuarios entre acciones y desde dónde se conectan. Cada una de ellas ya está en tus registros.
Extrae esas cuatro, aplica la Ley de Little para obtener una cifra de concurrencia respaldada por datos, y da forma a la rampa para que coincida con una hora real en lugar de una línea recta. Luego valida la ejecución contra producción y ajusta. Es más trabajo que elegir un número redondo de usuarios virtuales y es la única versión de la prueba cuyos resultados puedes usar.
Prueba tu modelo de tráfico en navegadores reales
LoadView ejecuta tus flujos de sesión en navegadores reales desde más de 40 zonas AWS y Azure, con curvas de carga que puedes moldear según el patrón de llegada que mediste. Los planes de pruebas de carga empresariales incluyen subcuentas, SSO y migración de scripts desde herramientas heredadas.
Programa una demo con un ingeniero de rendimiento de LoadView para recorrer tu modelo de tráfico.