Performance testing: load, stress and spikes explained

La demo salió redonda. Tú, el diseñador y un inversor navegando la app: cada clic responde al instante, cada pantalla carga sin pestañear. Firmas el lanzamiento. Tres semanas después, campaña al aire, treinta mil personas entran a la vez en la primera hora y el servidor se arrodilla. La pregunta que nadie hizo a tiempo era simple: ¿qué pasa cuando no somos tres, sino miles?

Esa pregunta no se responde con opinión ni con fe. Se responde con una medición hecha a propósito, antes de que la haga por ti el peor día posible. A eso se dedican las pruebas de rendimiento: someter el sistema a demanda controlada y mirar los números en frío. No preguntan "¿funciona?", preguntan "¿cuánto aguanta, y cómo se rompe?".

01 · la familiaNo es una prueba, son cuatro perfiles distintos

"Prueba de rendimiento" es un paraguas. Debajo hay tipos con objetivos diferentes, y confundirlos es la primera fuente de resultados inútiles. La norma ISO/IEC 25010 agrupa todo esto bajo la característica de eficiencia de desempeño: comportamiento temporal, uso de recursos y capacidad [1]. Dentro de ese paraguas, cuatro perfiles hacen el trabajo pesado.

Carga (load). Aplicas la demanda que esperas en producción, la realista: el pico de un martes normal, la campaña planificada. Preguntas si el sistema cumple sus objetivos de latencia y throughput bajo esa carga esperada. Es la prueba de "¿sirve para lo que prometimos?".

Estrés (stress). Aquí subes la demanda por encima de lo esperado, deliberadamente, hasta que algo cede. No buscas confirmar que aguanta: buscas encontrar el punto exacto donde deja de aguantar y ver cómo se comporta al romperse. ¿Devuelve errores limpios o se cae en silencio? ¿Se recupera solo cuando baja la carga o hay que reiniciar a mano?

Picos (spike). Un caso especial de estrés, pero por la forma de la curva. En vez de subir gradual, disparas la carga de golpe, de casi nada a muchísimo en segundos, como cuando sale al aire un anuncio en la final o abre la venta de entradas. Mides si el sistema absorbe el golpe o colapsa antes de poder reaccionar.

Resistencia (soak). Aplicas una carga moderada pero durante horas o días. No buscas el límite instantáneo, sino lo que se degrada con el tiempo: fugas de memoria, conexiones que no se liberan, discos que se llenan de logs. Cosas que en cinco minutos son invisibles y en doce horas tumban el servidor.

Carga pregunta si aguanta lo esperado. Estrés pregunta por dónde se rompe. No son la misma prueba.

02 · el termómetroQué métricas miras, y por qué el promedio miente

Correr la prueba es la mitad fácil. La otra mitad es leer los números correctos. Tres importan de verdad.

Latencia. Cuánto tarda una petición en responder. Aquí está la trampa más común: mirar el promedio. Si mil usuarios reciben respuesta en 100 ms y cien la reciben en 8 segundos, el promedio dice "700 ms, aceptable" y esconde a cien personas furiosas. Por eso se usan percentiles. El p95 es el tiempo bajo el cual responde el 95 % de las peticiones; el p99, el 99 %. Un p99 de 8 segundos significa que una de cada cien peticiones tarda eso o más. En un sitio con millones de visitas, ese 1 % son miles de personas reales.

Throughput. Cuántas peticiones procesa el sistema por segundo. Es la medida de capacidad: no cuánto tarda una, sino cuántas despacha en paralelo. Un sistema puede tener latencia baja y aun así ahogarse si el throughput tope es menor que la demanda.

Tasa de errores. Qué porcentaje de peticiones falla bajo carga. Latencia y throughput sin tasa de error engañan: de nada sirve responder rápido si la mitad de las respuestas son un 500.

03 · el métodoCómo se corre sin engañarte a ti mismo

Una prueba de rendimiento mal montada es peor que ninguna, porque te da confianza falsa. Cuatro reglas evitan los engaños más comunes.

Define el criterio antes de medir. Un número sin umbral no dice nada. "p95 por debajo de 500 ms con 10 000 usuarios concurrentes y menos de 0,1 % de errores" es un criterio; "queremos que sea rápido" es un deseo. El objetivo se fija primero, con base en el negocio, no después de ver los resultados para que encajen.

Mide en un entorno parecido a producción. Correr la carga contra tu portátil no predice nada del servidor real. Si el entorno de prueba tiene la mitad de memoria o una base de datos vacía, los números son ficción. Cuanto más se parezca a producción, más creíble el resultado.

Sube por escalones, no de un salto. Salvo cuando pruebas picos a propósito, incrementa la carga gradualmente. Así ves dónde empieza a doblarse la curva de latencia, no solo que al final se rompió. El punto en que el throughput deja de crecer aunque metas más usuarios es tu límite real de capacidad.

Mira también las tripas. Latencia y errores te dicen que algo va mal; CPU, memoria, I/O de disco y conexiones abiertas te dicen por qué. Una prueba que solo mira el reloj del cliente encuentra el síntoma pero nunca la causa.

El sílabo del ISTQB lo resume con una idea que conviene tatuarse: el testing no demuestra la ausencia de defectos, solo su presencia [3]. Una prueba de rendimiento que pasa no garantiza que el sistema nunca se caiga; garantiza que, bajo las condiciones que probaste, se comportó dentro de tus umbrales. Por eso las condiciones importan tanto como el resultado.

El objetivo no es un sello de "aprobado". Es saber, con números, dónde vive tu límite antes de que lo encuentre un cliente.

Volvamos a la demo del principio. La diferencia entre firmar tranquilo y firmar con los ojos cerrados no es el talento del equipo ni la calidad del código. Es una tarde de trabajo simulando treinta mil usuarios antes de que lleguen de verdad, leyendo el p99 en vez del promedio, y anotando el número exacto donde el sistema empieza a sudar. Ese número no se adivina. Se mide. Y medirlo a tiempo es más barato que descubrirlo el día del lanzamiento.