60 30/03/2026 07/04/2026 9 min

k6 è uno strumento moderno per eseguire test di carico e di performance su API, siti web e servizi backend. È pensato per essere semplice da usare, ma abbastanza flessibile da coprire scenari reali: picchi di traffico, verifiche di latenza, test di stabilità e controlli continui in pipeline CI/CD. In pratica, ti aiuta a rispondere a una domanda concreta: il servizio regge quando arrivano più utenti o più richieste del normale?

Questa guida mostra come installare k6, preparare il primo script, avviare un test e leggere i risultati in modo utile. L’obiettivo non è fare teoria, ma arrivare rapidamente a un test ripetibile e verificabile.

Perché usare k6

k6 è adatto a chi lavora con hosting, WordPress, API, e-commerce, pannelli di controllo e applicazioni custom. Rispetto ad altri strumenti storici, ha una curva di apprendimento abbastanza lineare e usa JavaScript per descrivere gli сценарi di test. Questo rende più facile costruire test leggibili e versionabili.

Le situazioni tipiche in cui ha senso usarlo sono:

  • verificare il comportamento di un sito prima di una campagna marketing;
  • misurare la capacità di un endpoint API sotto carico;
  • controllare se una cache funziona davvero;
  • capire dove si alzano i tempi di risposta;
  • testare la stabilità dopo modifiche a PHP, database, CDN o web server.

Se il tuo obiettivo è osservare metriche concrete come latenza, error rate, throughput e tempo di risposta al crescere del carico, k6 è una scelta solida.

Installazione di k6

La modalità più pratica dipende dal sistema operativo. Sui server Linux più comuni, l’installazione via repository è spesso la strada migliore perché consente aggiornamenti semplici e pacchetti mantenuti.

Ubuntu e Debian

Su sistemi Debian-based, puoi installare k6 tramite il repository ufficiale. In genere il flusso è questo:

sudo apt update
sudo apt install -y gnupg ca-certificates curl

Poi aggiungi il repository di k6 e installa il pacchetto. Il metodo preciso può variare nel tempo, quindi conviene seguire sempre la documentazione ufficiale del progetto: https://grafana.com/docs/k6/latest/set-up/install-k6/

Dopo l’installazione, verifica subito la versione:

k6 version

Esito atteso: viene mostrata una versione valida, senza errori di comando non trovato.

AlmaLinux, Rocky Linux e CentOS

Su distribuzioni RPM-based, il procedimento è simile: si configura il repository e si installa il pacchetto. Anche in questo caso il riferimento più sicuro resta la documentazione ufficiale, perché le istruzioni possono cambiare tra release.

Dopo l’installazione, controlla che il binario sia disponibile:

which k6

Esito atteso: viene restituito un percorso come /usr/bin/k6 o equivalente.

macOS

Su macOS, il metodo più comodo è spesso Homebrew:

brew install k6

Verifica poi con:

k6 version

Se non usi Homebrew, puoi installare il binario manualmente, ma per la maggior parte dei casi Homebrew è la soluzione più rapida e pulita.

Windows

Su Windows, k6 può essere installato tramite pacchetto dedicato o con gestori come Chocolatey, se già usati in ambiente aziendale. Dopo l’installazione, apri PowerShell e controlla:

k6 version

Se il comando non viene riconosciuto, il problema è quasi sempre nel PATH o nell’installazione incompleta.

Primo test: come funziona uno script k6

k6 usa script JavaScript per definire cosa testare, per quanto tempo e con quanti utenti virtuali. Il concetto base è semplice: un certo numero di utenti virtuali esegue richieste verso una destinazione, mentre k6 registra le metriche di risposta.

Un file minimo potrebbe essere questo:

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

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

export default function () {
  http.get('https://example.com');
  sleep(1);
}

In questo esempio:

  • vus: 10 indica 10 utenti virtuali;
  • duration: '30s' definisce una durata di 30 secondi;
  • http.get() esegue la richiesta;
  • sleep(1) introduce una pausa tra le iterazioni.

Salva questo script in un file, ad esempio test.js.

Avvio del test

Per eseguire il test, basta lanciare k6 sul file creato:

k6 run test.js

Durante l’esecuzione vedrai un riepilogo con metriche importanti come:

  • http_req_duration: tempo totale della richiesta;
  • http_req_failed: percentuale di richieste fallite;
  • http_reqs: numero di richieste effettuate;
  • vus: utenti virtuali attivi;
  • iterations: cicli completati.

Per un test utile, non guardare solo il tempo medio. Osserva anche i percentili, perché il comportamento sotto carico spesso si vede meglio su p95 e p99 che sulla media.

Configurazione più utile: scenari e soglie

Il vero valore di k6 emerge quando passi dal test base a uno scenario più realistico. Invece di fissare solo utenti e durata, puoi modellare ramp-up, plateau e picchi.

Un esempio più completo:

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

export const options = {
  scenarios: {
    normal_load: {
      executor: 'constant-vus',
      vus: 20,
      duration: '2m',
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  http.get('https://example.com');
  sleep(1);
}

Qui hai due elementi importanti:

  • scenarios, per definire il tipo di carico;
  • thresholds, per stabilire criteri di successo o fallimento.

Le soglie sono fondamentali perché trasformano il test da semplice raccolta dati a verifica automatica. Se il p95 supera i 500 ms o se gli errori superano l’1%, il test segnala un problema concreto.

Come testare endpoint autenticati

Molti casi reali coinvolgono API protette da token, cookie o header custom. k6 gestisce facilmente questi scenari.

Per esempio, puoi aggiungere un header di autorizzazione:

import http from 'k6/http';

export default function () {
  const params = {
    headers: {
      Authorization: 'Bearer TOKEN_REDATTO',
    },
  };

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

Se il test richiede sessioni con login, spesso conviene separare la fase di autenticazione dalla fase di carico principale. In questo modo eviti di stressare il login più del necessario e misuri meglio il comportamento del servizio reale.

Se nel tuo ambiente i token scadono rapidamente, usa variabili d’ambiente o file di configurazione esterni, così non devi modificare lo script ogni volta.

Uso delle variabili d’ambiente

Per rendere gli script più riutilizzabili, è utile passare l’URL o altri parametri da variabili d’ambiente. Questo ti permette di eseguire lo stesso test su staging, produzione o su più domini.

import http from 'k6/http';

export default function () {
  const baseUrl = __ENV.BASE_URL || 'https://example.com';
  http.get(`${baseUrl}/`);
}

Avvio con variabile:

BASE_URL=https://staging.example.com k6 run test.js

Esito atteso: il test colpisce l’ambiente specificato senza dover cambiare codice.

Interpretare i risultati

La lettura corretta dei risultati è il punto che separa un test utile da uno solo “rumoroso”. I dati da guardare davvero sono pochi, ma vanno letti bene.

  • Tempo medio: utile, ma non basta da solo.
  • p95 e p99: mostrano la coda di latenza, spesso più importante della media.
  • Error rate: se cresce, il sistema sta cedendo o degradando.
  • Request rate: indica quante richieste riesci a sostenere.
  • Trend nel tempo: un test che degrada dopo 60 secondi può rivelare memory leak, saturazione CPU o problemi di connessione al database.

Un buon approccio è confrontare il comportamento prima e dopo una modifica. Per esempio:

  • prima della cache;
  • dopo la cache;
  • prima e dopo un upgrade PHP;
  • prima e dopo un cambio di hosting o CDN.

Se il test peggiora, non fermarti alla superficie. Controlla CPU, RAM, I/O disco, connessioni al database, timeout del web server e eventuali limiti del provider.

Errori comuni e come risolverli

Durante i primi test, gli errori più frequenti sono quasi sempre semplici da diagnosticare.

Comando non trovato

Se k6 non viene riconosciuto, verifica l’installazione e il PATH:

which k6

Se non restituisce nulla, il binario non è installato correttamente oppure non è nel PATH.

Errore di connessione o timeout

Se il target risponde lentamente o va in timeout, il problema può essere reale e non nello script. In questo caso controlla:

  • DNS e raggiungibilità del dominio;
  • stato del web server;
  • eventuali firewall o rate limit;
  • log applicativi e del proxy.

Se stai testando un ambiente protetto, verifica che il tuo IP non sia bloccato da WAF, fail2ban o regole CDN.

Risposte 403 o 401

Di solito indicano autenticazione mancante o token errato. Controlla header, cookie, endpoint e scadenza delle credenziali.

Troppi errori sotto carico

Se il sistema fallisce troppo presto, riduci il numero di utenti e aumenta gradualmente il carico. Un test ben fatto cresce a scalini, non a caso.

Buone pratiche prima di lanciare un test

Un test di carico serio va preparato con attenzione, soprattutto in ambienti di produzione o quasi-produzione.

  • Esegui prima il test su staging, se disponibile.
  • Avvisa chi gestisce infrastruttura, CDN e monitoraggio.
  • Parti con carico basso e aumenta gradualmente.
  • Controlla metriche server e applicative in parallelo.
  • Salva sempre script e risultati per confronti futuri.

Se il sito o l’API sono critici, considera anche un piano di rollback: sospendere il test, ripristinare cache, ridurre gli utenti virtuali o cambiare finestra oraria.

Integrazione con CI/CD

Uno dei vantaggi di k6 è la possibilità di eseguire test in pipeline. Questo è molto utile quando vuoi impedire che una modifica peggiori le prestazioni senza accorgertene.

In un flusso CI, puoi far partire k6 dopo il deploy su staging e bloccare il rilascio se le soglie non sono rispettate. In questo modo il test diventa parte del controllo qualità, non un’attività occasionale.

Il principio è semplice: il codice non è pronto solo perché funziona, ma perché continua a funzionare bene sotto carico.

Quando usare k6 e quando no

k6 è ottimo per test HTTP, API e scenari scriptabili. È meno adatto se ti servono simulazioni estremamente complesse di navigazione browser reale o interazioni visuali avanzate. In quei casi può essere utile affiancarlo ad altri strumenti, ma per la maggior parte dei test di performance web e API è più che sufficiente.

Se lavori con WordPress, WooCommerce, Laravel, API REST o microservizi, k6 è spesso uno strumento perfetto per ottenere risposte rapide e misurabili.

Conclusione operativa

Il modo migliore per usare k6 è partire semplice: installazione, primo script, un test breve, lettura delle metriche. Poi aggiungi complessità solo quando serve, introducendo scenari, soglie, variabili d’ambiente e integrazione CI. Questo approccio evita test confusi e rende i risultati davvero confrontabili nel tempo.

Se vuoi usarlo bene, il punto non è generare più traffico possibile, ma generare traffico utile, cioè coerente con il comportamento reale dei tuoi utenti. È lì che k6 diventa uno strumento concreto per webmaster, sysadmin e chi gestisce siti e servizi in produzione.