160 30/03/2026 07/04/2026 11 min

k6 Tests: test di carico per verificare prestazioni e tenuta

Quando un sito funziona in condizioni normali ma crolla appena arrivano più utenti, il problema non è quasi mai “il server è lento” in senso generico. Il punto vero è capire cosa regge, cosa degrada e dove si rompe: PHP, database, cache, rete, filesystem, proxy, CDN, codice applicativo o configurazione del web server. k6 è uno strumento molto utile proprio per questo: permette di simulare carico realistico, osservare metriche affidabili e ripetere i test in modo controllato.

In pratica, k6 serve per rispondere a domande concrete: quante richieste al secondo regge il sito? Dove cresce la latenza? Il database entra in saturazione prima del web server? La cache migliora davvero il TTFB? Le API restano stabili sotto picco? Senza misurazioni, si ottimizza a sensazione. Con k6, invece, si lavora su numeri verificabili.

Perché usare k6

k6 è pensato per test di carico moderni, soprattutto su HTTP API, siti web e microservizi. Rispetto ad altri strumenti più vecchi, ha una sintassi chiara, scenari configurabili e un’ottima attenzione alle metriche. È adatto sia a chi gestisce un singolo sito WordPress sia a chi lavora con infrastrutture più articolate su VPS, cluster o ambienti cloud.

I vantaggi pratici sono questi:

  • puoi definire test semplici o complessi con pochi file;
  • puoi simulare utenti reali, con ramp-up e picchi;
  • puoi controllare soglie di errore e latenze;
  • puoi integrare i test in pipeline CI/CD;
  • puoi confrontare il comportamento prima e dopo un’ottimizzazione.

Il punto forte non è solo “fare tante richieste”, ma capire la tenuta del sistema in condizioni ripetibili.

Cosa misurare davvero

Un test di carico utile non si limita al numero di richieste. Per interpretare bene i risultati, conviene osservare almeno queste metriche:

  • latency e soprattutto i percentili, come p95 e p99;
  • error rate, cioè quante richieste falliscono;
  • throughput, ad esempio richieste al secondo;
  • TTFB, fondamentale per siti web e CMS;
  • CPU, RAM e I/O disco sul server;
  • slow query e saturazione del database;
  • cache hit rate su page cache, object cache o reverse proxy.

Se fai un test e vedi solo “la media risposta è 350 ms”, hai ancora poche informazioni. Se invece osservi che il p95 sale oltre 2 secondi, il database va in saturazione e il numero di errori aumenta dopo 80 utenti simultanei, hai finalmente un quadro utile.

Preparazione prima del test

Prima di lanciare k6 su un ambiente reale, conviene preparare il terreno. Un test di carico mal pianificato può confondere le analisi o, peggio, disturbare la produzione.

  1. Usa un ambiente di staging quando possibile. Se devi testare in produzione, scegli finestre di bassa attività e carichi graduali.
  2. Definisci un obiettivo: vuoi testare il login, la homepage, una ricerca, un checkout, una API specifica o l’intero flusso?
  3. Raccogli la baseline: tempi medi, CPU, RAM, query lente, stato cache e banda prima del test.
  4. Prepara il monitoraggio: log web server, log applicativi, metriche sistema, database e CDN se presente.
  5. Evita test ciechi: senza log e metriche lato server, il risultato di k6 da solo non basta.

Se il sito è già instabile, prima va stabilizzato il servizio. Il test di carico serve a misurare la tenuta, non a peggiorare un incidente in corso.

Installazione di k6

k6 è disponibile su più sistemi. In ambienti Linux moderni, l’installazione è semplice. Su Ubuntu/Debian e su Alma/Rocky/CentOS il metodo migliore dipende dalla versione, ma l’obiettivo è sempre avere una release stabile e aggiornata.

Su sistemi Debian/Ubuntu, in molti casi si usa il repository ufficiale. Su distribuzioni Enterprise Linux, spesso conviene usare il pacchetto per la propria versione o il binario ufficiale. Se preferisci non installare nulla sul server target, puoi eseguire i test da una macchina separata, meglio se vicina in rete e con risorse stabili.

Un controllo base dopo l’installazione è verificare la versione e l’aiuto del comando:

k6 version
k6 help

Se il comando risponde correttamente, puoi iniziare a creare il primo scenario.

Il primo test semplice

Il modo più pulito per partire è testare una sola pagina o endpoint, con pochi utenti e durata breve. Questo serve per verificare la correttezza dello script e la forma delle metriche.

Ecco un esempio minimale di test per una homepage:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 5,
  duration: '30s',
};

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

Questo script fa una cosa sola: invia richieste alla homepage, controlla che il codice HTTP sia 200 e introduce una breve pausa. È un test semplice, ma già utile per capire se l’endpoint regge una pressione iniziale.

Per eseguirlo:

k6 run test.js

Il risultato atteso è vedere una parte con statistiche, percentili, errori e un riepilogo finale. Se compaiono errori di connessione, timeout o status diversi da 200, il problema può essere nel backend, nel proxy o nella configurazione del sito.

Come costruire un test realistico

Un test serio deve imitare il comportamento degli utenti, non solo bombardare il server con richieste casuali. Un sito reale riceve accessi distribuiti, con sessioni, tempi di lettura, navigazione tra pagine e talvolta autenticazione.

Per questo conviene modellare alcuni elementi:

  • ramp-up graduale: aumenti progressivi degli utenti;
  • picco controllato: una fase di massimo carico;
  • soak test: durata lunga per scoprire memory leak o accumuli;
  • mix di endpoint: homepage, pagine interne, login, API, ricerca;
  • think time: pause tra una richiesta e l’altra per simulare lettura reale.

Se stai testando WordPress, per esempio, ha senso includere homepage, una pagina articolo, la ricerca e magari un accesso autenticato. Se stai testando un’API, puoi includere endpoint pubblici e endpoint protetti con token, tenendo sempre separati i dati sensibili.

Esempio con più fasi

Un test più realistico può avere una crescita iniziale, un plateau e una discesa. In k6 questo si ottiene con gli scenari. Il vantaggio è che puoi osservare come cambia il sistema nei diversi momenti del carico.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 20 },
    { duration: '5m', target: 20 },
    { duration: '2m', target: 0 },
  ],
};

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

Questa struttura è adatta quando vuoi capire se il sito regge una pressione costante, non solo un picco breve.

Autenticazione, cookie e sessioni

Molti test devono passare da login, cookie o token. In questo caso k6 può gestire header personalizzati, payload JSON e sessioni. È fondamentale però non usare credenziali reali in modo disordinato: meglio account di test, dati fittizi e permessi minimi.

Per una chiamata autenticata, puoi inviare un header simile:

import http from 'k6/http';

export default function () {
  const params = {
    headers: {
      Authorization: 'Bearer TOKEN_DI_TEST',
      'Content-Type': 'application/json',
    },
  };

  http.get('https://api.example.com/me', params);
}

Se il servizio usa cookie di sessione, puoi gestirli direttamente con le richieste HTTP, ma è bene verificare sempre che il flusso sia coerente con il comportamento reale del browser o dell’applicazione.

Thresholds: quando il test fallisce davvero

Una delle funzioni più utili di k6 è la definizione delle soglie. Invece di leggere solo i numeri a posteriori, puoi dire in anticipo quali valori sono accettabili. Se il sistema li supera, il test risulta fallito.

Per esempio:

export const options = {
  thresholds: {
    http_req_duration: ['p(95)<800'],
    http_req_failed: ['rate<0.01'],
  },
};

Questo significa che vuoi il 95% delle richieste sotto gli 800 ms e meno dell’1% di errori. È un approccio molto utile in ambienti professionali, perché trasforma il test di carico in una verifica oggettiva, non in una semplice osservazione.

Le soglie sono particolarmente utili prima e dopo un intervento: ad esempio, dopo aver attivato una cache, ottimizzato query MySQL, aggiornato PHP o spostato il sito su un server più potente.

Come leggere i risultati

Il risultato di un test va interpretato con metodo. Alcuni segnali sono abbastanza chiari:

  • se la latenza cresce lentamente ma gli errori restano bassi, il sistema è sotto stress ma ancora stabile;
  • se la latenza sale di colpo e compaiono errori 5xx, c’è un collo di bottiglia serio;
  • se il throughput si ferma mentre il carico aumenta, il limite è stato raggiunto;
  • se la CPU resta bassa ma il tempo cresce, il problema può essere I/O, rete o database;
  • se il database registra query lente, il bottleneck è probabilmente nella parte applicativa o SQL.

In un sito ben ottimizzato, il comportamento dovrebbe essere abbastanza regolare fino a un certo punto, poi degradare in modo comprensibile. Se invece crolla in maniera caotica, spesso manca caching, ci sono query non indicizzate o il server non ha risorse adeguate.

Integrazione con monitoraggio esterno

k6 dà il lato client del problema. Per avere un quadro completo, devi affiancarlo al monitoraggio lato server. Durante il test osserva CPU, RAM, swap, load average, disco, rete, log di Nginx o Apache, PHP-FPM e database.

Se usi un pannello come cPanel, Plesk o FastPanel, controlla anche i grafici di utilizzo e gli error log. Se hai Prometheus, Grafana, Netdata o un sistema equivalente, il test diventa molto più leggibile. L’obiettivo è correlare il momento in cui k6 vede un aumento di latenza con il momento in cui il server mostra saturazione.

Questa correlazione è il cuore del troubleshooting serio: non basta sapere che qualcosa rallenta, bisogna capire quando e perché.

Errori comuni da evitare

Molti test di carico falliscono non per colpa del server, ma per errori metodologici. I più frequenti sono questi:

  • testare direttamente la produzione senza avviso o finestra di controllo;
  • usare un solo endpoint e trarre conclusioni generali su tutto il sito;
  • ignorare cache, CDN e reverse proxy;
  • non distinguere tra latenza di rete e tempo applicativo;
  • non salvare i risultati, rendendo impossibile il confronto;
  • fare test troppo brevi e confondere un picco momentaneo con la tenuta reale.

Un altro errore tipico è usare parametri troppo aggressivi all’inizio. Meglio partire basso, verificare il comportamento, poi aumentare gradualmente. È più sicuro, più leggibile e molto più utile per trovare il punto di rottura.

Uso pratico su siti WordPress

Su WordPress, i test di carico aiutano a capire se il problema è il tema, i plugin, il database o la cache. Un sito con page cache efficace può reggere molto più traffico rispetto a uno che genera ogni pagina dinamicamente.

In un contesto WordPress ha senso verificare:

  • homepage e pagine articolo con cache attiva;
  • pagina senza cache per confronto;
  • login e area admin, che non vanno confusi con il traffico pubblico;
  • ricerca interna, spesso più costosa;
  • checkout o form, se presenti.

Se il sito ha plugin pesanti, page builder o query complesse, k6 aiuta a far emergere il comportamento reale sotto pressione. Spesso il problema non è il numero assoluto di visitatori, ma la quantità di lavoro che ogni visita impone al server.

Buone pratiche operative

Per lavorare bene con i test di carico, conviene adottare alcune regole semplici ma robuste:

  1. documenta ogni test con data, target, durata e parametri;
  2. salva i risultati e confrontali nel tempo;
  3. mantieni separati ambienti di staging e produzione;
  4. modifica una variabile alla volta, così sai cosa ha cambiato il risultato;
  5. valuta sempre il test insieme ai log e alle metriche del server.

Questo approccio evita conclusioni affrettate. Se dopo un’ottimizzazione il sito migliora, vuoi sapere esattamente quale cambiamento ha prodotto l’effetto. Se invece peggiora, devi poter fare rollback con chiarezza.

Conclusione operativa

k6 è uno strumento molto efficace perché unisce semplicità e precisione. Ti permette di creare test di carico ripetibili, misurare la tenuta di un sito o di un’API e identificare i colli di bottiglia con dati concreti. Usato bene, non serve solo a “fare stress”: serve a prendere decisioni tecniche migliori su cache, database, PHP, web server e architettura.

Il metodo corretto è sempre lo stesso: definire un obiettivo, preparare l’ambiente, lanciare un test progressivo, leggere i risultati insieme ai log e correggere un punto alla volta. È così che un test di carico diventa uno strumento di diagnosi, non un esercizio di forza bruta.

Se vuoi usare k6 in modo professionale, pensa meno al numero di utenti e più alla qualità della misura. Un test ben costruito ti dice non solo quanto regge il sistema, ma anche dove conviene investire tempo per renderlo più veloce, stabile e prevedibile.

Un buon test di carico non dimostra che il server è forte: dimostra dove smette di esserlo, e con quale costo per l’utente finale.