Módulo 4 · Performance

4 horas — 1 h 30 de teoría, 2 h 30 de práctica.

Contenido en preparación

La parte teórica la desarrolla el instructor. Los ejercicios están completos y usan el laboratorio real.

Objetivos

• Explicar para qué sirven las pruebas de rendimiento.
• Distinguir carga, estrés, picos y resistencia.
• Interpretar tiempo de respuesta, throughput y tasa de error.
• Preparar y ejecutar un script de carga con umbrales.
• Analizar resultados y proponer una mejora concreta.

Contenidos teóricos

Tema	Tiempo
Objetivos de las pruebas de rendimiento	20 min
Tipos: carga, estrés, picos y resistencia	25 min
Métricas: tiempo de respuesta, throughput y errores	20 min
Herramientas de performance	15 min
Interpretación básica de resultados	10 min

Entregable

Un script de performance y un reporte con resultados, conclusiones y recomendaciones.

---

Las tres métricas que importan

Métrica	Qué mide	Trampa habitual
Tiempo de respuesta	Cuánto tarda una petición	Mirar el promedio. Se usa el p95: el promedio esconde a los usuarios que sufren.
Throughput	Peticiones por segundo	Un throughput alto con p95 alto significa que el sistema está encolando, no atendiendo.
Tasa de error	% de peticiones fallidas	Un sistema saturado puede seguir respondiendo 200 pero tardando 3 segundos. Sin errores ≠ sin problema.

La señal de saturación: el throughput se estanca y el p95 sube. El sistema ya no puede hacer más trabajo; lo único que crece es la cola.

Los tres scripts del laboratorio

Están en el repositorio del laboratorio, en performance/k6/, comentados en español. Los lanza el instructor.

Script	Qué hace	Para qué
smoke.js	5 usuarios, 1 minuto	Comprobar que el sistema funciona antes de medir nada
carga.js	Sube hasta 20 usuarios y mantiene	Ver si aguanta el uso esperado
estres.js	Sube hasta 60 usuarios	Encontrar el límite y ver cómo se comporta al pasarlo

Los umbrales están escritos dentro de cada script. Si no se cumplen, k6 termina con error: un umbral es un criterio de aceptación, no una sugerencia.

---

Ejercicio 1 · Preparar el script (35 min)

Lee performance/k6/smoke.js y responde:

1. ¿Qué hace la función setup() y por qué el login va ahí y no dentro de la prueba?
2. ¿Qué significa sleep(1) al final de la iteración? ¿Qué pasaría sin él?
3. ¿Para qué sirve la etiqueta tags: { name: '...' } en cada petición?
4. Los tres umbrales de smoke.js: explica qué mide cada uno.

Después lee estres.js y contesta la pregunta clave:

5. ¿Por qué inicia sesión como administrador y no como estudiante?

Respuesta a la 5, después de intentarlo

Cuando pregunta un cliente, la consulta filtra primero por su usuario, y ese filtro sí tiene índice: solo toca sus pocas citas. La vista de administrador pide todas las citas de un día sin filtrar por usuario, y ahí sí hay que recorrer la tabla completa. El mismo endpoint es rápido o lento según quién pregunte: un detalle que se escapa en muchas pruebas de rendimiento.

Ejercicio 2 · Configurar usuarios, duración y umbrales (30 min)

Diseña, sobre papel, una prueba de picos (spike): carga baja, un pico brusco, y vuelta a la carga baja.

export const options = {
	stages: [
		// completa esto
	],
	thresholds: {
		// y esto
	},
};

Justifica los números: ¿por qué ese pico? ¿por qué esa duración? ¿qué umbral consideras aceptable y de dónde sale ese criterio?

Ejercicio 3 · Ejecutar (20 min)

El instructor lanza, en este orden:

make metrics-up
make k6 SCRIPT=smoke.js
make k6 SCRIPT=estres.js

Mientras corren, mira el tablero en metrics.theproject.ec → ReservaLab · pruebas de carga.

Anota, para cada prueba: usuarios virtuales, peticiones por segundo, p95 y tasa de error.

Ejercicio 4 · Analizar y encontrar el problema (35 min)

Con los datos del estrés, contesta:

1. ¿A partir de cuántos usuarios el p95 empieza a subir de forma clara?
2. ¿El throughput sigue creciendo o se estanca? ¿Qué te dice eso?
3. ¿Hubo errores? Si no hubo, ¿significa que el sistema estaba bien?
4. En el panel Tiempo de respuesta por endpoint: ¿qué endpoint se degrada y cuál se mantiene estable? ¿Qué te dice esa diferencia?

Después, con el instructor, mira el plan de ejecución de la consulta:

EXPLAIN ANALYZE
SELECT COUNT(*) FROM appointments
WHERE fecha >= '2026-03-15'::date
  AND fecha <  '2026-03-16'::date;

5. ¿Qué operación aparece? ¿Cuántas filas descarta el filtro?
6. ¿Qué índices existen sobre appointments y cuál falta?

SELECT indexname FROM pg_indexes WHERE tablename = 'appointments';

Ejercicio 5 · Conclusiones y recomendaciones (30 min)

El instructor aplica el índice que falta en vivo desde el panel de administración y se repite el estrés.

Compara el antes y el después y escribe el reporte:

	Sin índice	Con índice
Operación en el plan
p95 de la búsqueda por fecha
Umbral cumplido

Referencia de lo que debería salir

En las mediciones de preparación, el p95 pasó de 1,88 s a 55 ms — unas 34 veces más rápido — y el plan cambió de Parallel Seq Scan a Index Only Scan. Tus números pueden variar según cuántos estén trabajando a la vez.

Tu reporte debe contener:

1. Qué se midió: escenario, usuarios, duración.
2. Resultados: las tres métricas, antes y después.
3. Diagnóstico: la causa raíz, no el síntoma. "Va lento" no es un diagnóstico; "falta un índice sobre appointments.fecha, lo que fuerza un recorrido secuencial de 200.000 filas en cada petición" sí lo es.
4. Recomendación: la acción concreta y su efecto medido.
5. Riesgo residual: ¿qué otra cosa podría degradarse y no probamos?