Pruebas de rendimiento: cómo construir escenarios de carga realistas

Pruebas de rendimiento: cómo construir escenarios de carga realistas

Una prueba de carga puede ejecutarse correctamente y, aun así, responder una pregunta equivocada. Esto ocurre cuando el escenario solo repite solicitudes técnicas —por ejemplo, llamadas a una API en un bucle— sin representar cómo las personas utilizan realmente el producto ni cómo el negocio espera que evolucione la demanda.

Para que una prueba de rendimiento sirva para tomar decisiones de capacidad, es necesario transformar los recorridos críticos del negocio en un modelo de carga explícito. Ese modelo debe describir qué hacen los usuarios, con qué frecuencia, en qué orden, cuánto esperan entre acciones, qué datos utilizan y qué dependencias participan. En este artículo se explica cómo construirlo y cómo validar sus supuestos antes de ejecutar la prueba.

Qué debe representar un modelo de carga

Un modelo de carga es una representación operativa de la demanda que un sistema debe atender. No describe únicamente el volumen de tráfico: también incluye el comportamiento de los usuarios y las condiciones bajo las cuales se producen las solicitudes.

Como mínimo, conviene documentar los siguientes elementos:

• Recorridos de negocio: las secuencias de acciones que tienen valor para el usuario o para la operación.
• Mezcla de operaciones: la proporción relativa entre búsquedas, lecturas, escrituras, pagos, consultas administrativas u otros flujos.
• Distribución de usuarios: qué porcentaje de usuarios ejecuta cada recorrido.
• Tiempos de espera: pausas entre acciones, tiempos de lectura y posibles demoras causadas por dependencias externas.
• Datos de prueba: productos, cuentas, carritos, órdenes y estados necesarios para que el flujo sea válido.
• Sesiones: autenticación, cookies, tokens, carritos y cualquier otro estado que deba mantenerse entre solicitudes.
• Patrón temporal: inicio de usuarios, crecimiento de la carga, duración de la prueba y descenso posterior.

La precisión del modelo no depende de conocer cada detalle desde el primer momento. Sí depende de distinguir claramente qué información está confirmada, qué es una hipótesis y qué debe medirse antes de ejecutar la prueba.

Convertir recorridos críticos en escenarios de carga

El punto de partida no debería ser un endpoint aislado, sino un recorrido completo. Un recorrido puede involucrar varios servicios, consultas a bases de datos, sistemas de identidad, proveedores de pago, colas o APIs de terceros.

Por ejemplo, para un e-commerce hipotético, claramente utilizado solo como ejemplo conceptual, podrían identificarse estos recorridos:

• Explorar el catálogo: consultar categorías, aplicar filtros y abrir el detalle de un producto.
• Comprar: iniciar sesión, agregar productos al carrito, revisar el resumen, seleccionar una opción de entrega y confirmar la orden.
• Consultar una orden: acceder al historial y revisar el estado de una compra.
• Operar el catálogo: actualizar inventario o información de productos desde una interfaz interna.

Cada recorrido debería descomponerse en pasos funcionales y técnicos. Por ejemplo, el flujo de compra podría requerir:

1. Obtener o renovar la sesión del usuario.
2. Consultar el detalle de uno o más productos.
3. Crear o actualizar el carrito.
4. Calcular totales, impuestos o costos de entrega.
5. Confirmar la orden.
6. Publicar o procesar eventos asociados, si la arquitectura los utiliza.

Esta descomposición permite observar dónde se concentra el costo. También evita una interpretación frecuente pero incompleta: asumir que una prueba sobre el endpoint de creación de órdenes representa por sí sola la experiencia de compra.

Definir la mezcla de operaciones

La mezcla de operaciones expresa cómo se distribuyen los recorridos dentro de la carga. No es necesario que todos los usuarios hagan lo mismo. Un escenario puede incluir muchos usuarios que consultan el catálogo, una proporción menor que agrega productos al carrito y un subconjunto que completa una compra.

La distribución debe basarse, cuando sea posible, en datos observados del sistema: métricas de acceso, analítica de producto, registros de aplicación, eventos de negocio o conocimiento de los responsables operativos. Si todavía no existen datos confiables, la distribución debe registrarse como un supuesto y validarse antes de usarla para una decisión de capacidad.

Usuarios concurrentes, solicitudes por segundo y resultados observables

Estos conceptos se relacionan, pero no son equivalentes.

• Usuarios concurrentes: representan cuántos usuarios virtuales están activos o ejecutando un recorrido en un momento determinado. Un usuario puede estar esperando, pensando o procesando una respuesta.
• Solicitudes por segundo: representan la tasa de solicitudes que llegan a un servicio o endpoint. Dependen del número de usuarios, la duración de los flujos, los tiempos de espera y la cantidad de llamadas que genera cada acción.
• Resultados observables: son las evidencias que permiten evaluar el comportamiento, como latencia, errores, saturación de recursos, tiempos de cola, consumo de conexiones o retrasos en procesos asíncronos.

Un mismo número de usuarios concurrentes puede producir tasas de solicitudes diferentes. Si los usuarios esperan más tiempo entre acciones, la tasa puede disminuir. Si un recorrido realiza varias llamadas en paralelo o repite operaciones, puede aumentar. Por eso no conviene presentar una cantidad de usuarios como si fuera automáticamente una tasa de tráfico.

Del mismo modo, alcanzar una tasa objetivo no demuestra que la experiencia sea aceptable. La prueba debe observar tanto la generación de carga como el comportamiento del sistema: latencias por percentiles, códigos de error, respuestas incompletas, timeouts, saturación de CPU, memoria, conexiones, almacenamiento, bases de datos y dependencias externas.

Cómo modelar usuarios, pausas y sesiones

Ramp-up y duración

El ramp-up define cómo se incorporan los usuarios virtuales. Una incorporación gradual ayuda a observar cuándo aparecen cambios de comportamiento y a diferenciar problemas de inicialización de problemas de saturación. Una incorporación abrupta puede ser apropiada si el riesgo que se quiere evaluar es precisamente una llegada repentina, pero debe representar una situación operativa plausible.

La duración también debe responder a una pregunta concreta. Una prueba breve puede servir para verificar una capacidad inicial o detectar errores evidentes. Una prueba sostenida permite observar acumulación de conexiones, crecimiento de colas, fugas de memoria, agotamiento de pools o degradación progresiva. No existe una duración universal: depende del riesgo que se busca evaluar y de la dinámica del sistema.

Think time y pausas entre acciones

Los usuarios no suelen enviar solicitudes sin pausa. Leen una página, comparan opciones o completan un formulario. Estas pausas se conocen habitualmente como think time.

Eliminar todas las pausas puede producir un escenario más intenso, pero también puede alejarse del uso real. Incluirlas sin criterio tampoco es suficiente: deben reflejar, al menos de forma aproximada, el comportamiento esperado o el objetivo de la prueba. Es recomendable documentar si una pausa representa una acción humana, una demora de red o una espera deliberada del flujo.

Sesiones y datos correlacionados

Los escenarios realistas requieren datos y estados válidos. Una prueba de compra, por ejemplo, puede necesitar usuarios autenticados, carritos independientes, productos disponibles y tokens obtenidos durante la ejecución. Reutilizar siempre la misma sesión o el mismo carrito puede ocultar problemas de concurrencia, bloqueo, caché o aislamiento de datos.

También es importante considerar la correlación: un identificador generado en una respuesta puede ser necesario en una solicitud posterior. Si el escenario no conserva correctamente ese estado, la prueba puede terminar midiendo errores de preparación en lugar del rendimiento del sistema.

Datos de prueba y dependencias del escenario

Los datos no son un detalle secundario. Pueden cambiar el comportamiento de las consultas, el uso de caché, la distribución de resultados y la contención sobre registros específicos.

Antes de ejecutar, conviene definir:

• Qué entidades serán compartidas y cuáles serán exclusivas por usuario virtual.
• Qué estados son válidos para cada recorrido.
• Cómo se crearán, renovarán o limpiarán los datos.
• Si los datos representan una distribución razonable de tamaños, categorías y estados.
• Qué operaciones no deben ejecutarse contra sistemas productivos.

Las dependencias externas también deben clasificarse. Un proveedor de pagos, un servicio de identidad o una API de envío puede participar de la prueba de varias maneras: como dependencia real bajo condiciones controladas, como servicio simulado o como componente excluido con una justificación explícita.

Simular una dependencia puede facilitar el aislamiento de un servicio, pero elimina parte del comportamiento real, como sus límites de tasa, latencia, errores y disponibilidad. Utilizar la dependencia real puede ofrecer mayor fidelidad, aunque requiere autorización, coordinación y controles para evitar efectos operativos o transacciones no deseadas.

Qué medir para interpretar la prueba

Un escenario de carga útil necesita criterios de éxito definidos antes de comenzar. Estos criterios deben combinar métricas técnicas y resultados de negocio.

• Latencia: observar percentiles y no únicamente promedios, porque un promedio puede ocultar una cola de respuestas lentas.
• Errores: distinguir códigos HTTP, excepciones, timeouts, respuestas inválidas y fallos funcionales.
• Throughput: medir solicitudes, transacciones o recorridos completados, indicando claramente cuál es la unidad.
• Recursos: revisar CPU, memoria, pools de conexiones, colas, almacenamiento, red y dependencias críticas.
• Consistencia: verificar que las operaciones completadas produzcan resultados correctos, especialmente en carritos, pagos, inventario y órdenes.
• Procesamiento asíncrono: medir el retraso de eventos, mensajes o tareas que no terminan dentro de la respuesta inicial.

Un resultado observable debe relacionarse con una decisión. Por ejemplo, un aumento de latencia junto con saturación de conexiones puede orientar una investigación diferente que la misma latencia acompañada por errores de una dependencia externa. Sin contexto, una métrica aislada rara vez explica la causa.

Errores frecuentes al diseñar escenarios de carga

• Probar solo endpoints: facilita la automatización, pero puede ignorar la secuencia y el estado de los recorridos reales.
• Usar una única operación: una carga homogénea no representa necesariamente la mezcla del negocio.
• Confundir usuarios con solicitudes por segundo: conduce a objetivos mal definidos y a conclusiones difíciles de comparar.
• Eliminar todas las pausas: puede convertir el escenario en un generador artificial de tráfico.
• Reutilizar datos y sesiones: puede ocultar contención o producir errores que no reflejan el uso real.
• No validar el flujo funcional: una prueba puede generar tráfico sin completar realmente el recorrido.
• No observar las dependencias: el sistema bajo prueba puede parecer lento cuando el cuello de botella está fuera de él.
• Definir conclusiones antes de medir: una prueba debería confirmar o refutar supuestos, no justificar una respuesta predeterminada.

Cómo validar los supuestos antes de ejecutar

Antes de iniciar una prueba de carga, conviene revisar el modelo con las personas que conocen el producto, la operación y la plataforma. El objetivo es detectar diferencias entre lo que el equipo cree que ocurre y lo que realmente ocurre.

Una lista de validación puede incluir estas preguntas:

• ¿Cuáles son los recorridos críticos para el negocio?
• ¿Qué proporción de usuarios ejecuta cada recorrido?
• ¿La carga esperada representa un periodo normal, un evento puntual o un crecimiento futuro?
• ¿La concurrencia se refiere a usuarios conectados, usuarios activos o transacciones en curso?
• ¿Qué datos y estados necesita cada flujo?
• ¿Qué dependencias deben estar activas, simuladas o excluidas?
• ¿Cuáles son los criterios funcionales y técnicos para considerar exitosa la prueba?
• ¿Cómo se correlacionarán los resultados con métricas de aplicación, infraestructura y negocio?

También es recomendable ejecutar primero una validación funcional con poca carga. Esta etapa confirma que las sesiones, los datos, las correlaciones y las reglas de negocio funcionan antes de incorporar volumen. Después puede agregarse una carga pequeña para comprobar que las métricas y los paneles de observabilidad permiten interpretar lo que ocurre.

Conclusión: probar la demanda correcta antes de dimensionar

Una prueba de rendimiento útil no comienza con una herramienta ni con un número arbitrario de usuarios. Comienza con una descripción verificable de cómo se utiliza el sistema: recorridos, mezcla de operaciones, pausas, sesiones, datos, dependencias y patrón temporal.

La decisión principal es separar claramente los hechos de los supuestos. Los usuarios concurrentes, las solicitudes por segundo y los resultados observables deben definirse por separado para evitar conclusiones ambiguas. Después, el modelo debe validarse con datos operativos y con una ejecución funcional controlada.

Antes de lanzar una prueba de carga, documenta los recorridos críticos y sus supuestos. Si necesitas validarlos, solicita una evaluación de rendimiento a Mentores Tech.