Performance Testing — Cheat Sheet

Tag: performance, load, stress, k6, jmeter, throughput, latency

Livello: intermedio

TL;DR: Sintesi su concetti, metriche e tipologie di test per valutare prestazioni, scalabilità e affidabilità di un sistema sotto carico.

Concetti chiave

Load Testing: Verifica che il sistema gestisca in modo stabile il carico di utenti concorrenti atteso.

Stress Testing: Aumento del carico oltre i limiti previsti per trovare il punto di rottura (breaking point) e valutare il recupero.

Spike Testing: Simulazione di un picco di traffico improvviso e massiccio per vedere come reagiscono autoscaling e risorse.

Soak Testing (Endurance): Carico sostenuto per ore o giorni per identificare memory leak o degrado delle prestazioni nel tempo.

Throughput: Quantità di richieste elaborate nel tempo, tipicamente misurata in Requests Per Second (RPS) o Transactions Per Second (TPS).

Tempo di risposta (Latency): Tempo totale impiegato dal sistema per ricevere la richiesta ed emettere il primo byte o l'intera risposta.

Percentili (p95, p99): Valori sotto i quali ricade il 95% o il 99% dei tempi di risposta. Più affidabili della media aritmetica.

Collo di bottiglia (Bottleneck): Il componente (CPU, memoria, rete, database) che satura per primo, limitando il throughput totale.

Domande tipiche e risposte pronte

Q: Che differenza c'è tra load testing e stress testing?R: Il load test verifica che il sistema regga il traffico che ci aspettiamo in produzione. Lo stress test serve ad affossarlo deliberatamente per capire quale componente cede per primo e come fallisce.

Q: Perché si usano i percentili p95/p99 invece della media?R: Perché la media nasconde i casi limite (outlier). Un p99 di 2 secondi mi assicura che il 99% degli utenti ha ricevuto risposta in 2 secondi o meno, dandomi un quadro reale dell'esperienza utente.

Q: Quali tool preferisci usare e perché?R: Prediligo k6 perché permette di scrivere i test in JavaScript come code-as-infrastructure ed è facile da integrare nelle pipeline CI/CD, rispetto alle UI più pesanti di JMeter.

Insidie e errori comuni

Usare la media aritmetica per valutare i tempi di risposta, ignorando l'esperienza degli utenti più lenti.

Testare in ambienti (hardware, rete, dati) non rappresentativi della produzione o senza un factor di scaling adeguato.

Dimenticare il "warm-up" del sistema (cache vuote, connessioni da stabilire), registrando tempi iniziali falsati.

Generare il carico dalla stessa macchina che ospita l'applicazione, creando competizione per le risorse.

Snippet e comandiJavaScript

// Esempio base di un test di carico con k6
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 20 }, // Rampa fino a 20 utenti
    { duration: '1m', target: 20 },  // Mantieni 20 utenti
    { duration: '30s', target: 0 },  // Rampa a scendere a 0 utenti
  ],
};

export default function () {
  const res = http.get('https://api.example.com/data');
  check(res, { 'status was 200': (r) => r.status == 200 });
  sleep(1);
}

Da ripassare

[ ] Profilazione avanzata e lettura dei dump per analizzare i colli di bottiglia su database (slow query).

[ ] Strategie di mock/stub per servizi di terze parti durante i test di performance.

Jarvis Interviews
Jarvis