Test di Carico con k6 — Come individuare i colli di bottiglia prima che ti facciano perdere clienti

Il tuo sito va bene con un utente. Con dieci ancora regge. Poi arriva il Black Friday, il lancio di una campagna, un post virale. E il server cade. Hai perso vendite, hai perso fiducia. Noi lo vediamo ogni giorno: aziende che scoprono i limiti della propria infrastruttura solo quando è troppo tardi. I test di performance non sono un optional. Sono quello che separa un sito professionale da una scommessa.

Come funziona k6 rispetto ad Artillery per il load testing?

k6 e Artillery sono due strumenti open-source per il carico, ma partono da filosofie diverse. k6 è scritto in Go, usa JavaScript per gli script, è pensato per integrarsi con CI/CD. Artillery è basato su Node.js, usa YAML/JSON per le configurazioni, ed è più semplice per test rapidi. Noi, di Meteora Web, abbiamo usato entrambi. k6 lo preferiamo quando serve una simulazione realistica con utenti virtuali che navigano pagine, inviano form, caricano file. Artillery lo teniamo per test di fumetto veloci su endpoint API.

La differenza chiave: k6 esegue il test in un processo Go single-thread, consuma meno risorse. Artillery, essendo Node, può essere più pesante con molti utenti. Se devi simulare 10.000 utenti, k6 vince. Se devi fare un test rapido su una singola rotta, Artillery è più immediato.

Esempio pratico: Test k6 su un form di contatto

Ecco uno script k6 che invia 5 richieste al secondo per 30 secondi a un endpoint POST:

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

export let options = {
  stages: [
    { duration: '30s', target: 5 },
  ],
};

export default function () {
  let url = 'https://tuosito.com/api/contatto';
  let payload = JSON.stringify({ nome: 'Test', email: 'test@example.com', messaggio: 'Carico simulato' });
  let params = { headers: { 'Content-Type': 'application/json' } };
  let res = http.post(url, payload, params);
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);
}

Cosa fa: ogni iterazione invia una POST, controlla lo status, poi aspetta 1 secondo. Il test scala linearmente fino a 5 iterazioni al secondo. Esegui con k6 run script.js.

Quale scegliere per test di performance: k6 o Artillery?

Dipende dal contesto. Se il tuo sito è basato su WordPress o un CMS tradizionale, e vuoi testare il caricamento di pagine intere (HTML, CSS, JS, immagini), k6 è più adatto perché puoi scrivere script complessi con estrazioni dati e cookie. Artillery è meglio per API semplici: definisci uno YAML con le richieste e via.

Un caso concreto: un nostro cliente e-commerce con WooCommerce. Prima del lancio di una promozione, abbiamo usato k6 per simulare 50 utenti che navigano, aggiungono al carrello e checkout. k6 ci ha permesso di impostare i cookie di sessione e il carrello. Con Artillery avremmo dovuto scrivere più codice manuale. Invece con k6 è stato lineare.

Se invece devi testare una microservizio isolato (es. API di login), Artillery è più veloce da configurare. Ecco un esempio Artillery:

config:
  target: 'https://api.tuoservizio.com'
  phases:
    - duration: 60
      arrivalRate: 10
scenarios:
  - flow:
    - post:
        url: '/login'
        json:
          username: 'test'
          password: 'test'
        capture:
          - json: '$.token'
            as: 'token'

Esegui con artillery run test.yml. Semplice, no?

Come scrivere un test di carico con k6 che simuli utenti reali?

Un errore comune: testare solo l'endpoint, non il flusso utente. Un utente reale arriva dalla homepage, clicca, cerca, compila. Dovresti replicarlo. k6 ti permette di creare script con più passaggi, estrarre dati dalle risposte e usarli nelle richieste successive. Ecco un esempio di flusso di acquisto semplificato:

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

export default function () {
  // 1. Homepage
  let home = http.get('https://tuonegozio.com/');
  check(home, { 'homepage OK': (r) => r.status === 200 });
  sleep(2);

  // 2. Cerca un prodotto
  let search = http.get('https://tuonegozio.com/?s=camicia');
  check(search, { 'ricerca OK': (r) => r.status === 200 });
  sleep(1);

  // 3. Aggiungi al carrello
  let addCart = http.post('https://tuonegozio.com/carrello', {
    product_id: 123,
    quantity: 1
  });
  check(addCart, { 'aggiunto carrello': (r) => r.status === 200 });
  sleep(1);

  // 4. Pagina checkout
  let checkout = http.get('https://tuonegozio.com/checkout/');
  check(checkout, { 'checkout OK': (r) => r.status === 200 });
  sleep(1);
}

Nota: abbiamo usato sleep() per simulare il tempo di lettura. Puoi variare i tempi con random per simulare comportamento umano. k6 ha anche il modulo k6/execution per ottenere dati come VU ID.

Come interpretare i risultati di un test di carico?

Due metriche fondamentali: tempo di risposta (95° percentile) e tasso di errore. Se il 95° percentile supera i 2 secondi per una pagina, devi ottimizzare. Se ci sono errori 5xx, il server non regge. k6 produce un output dettagliato. Noi guardiamo sempre il grafico http_req_duration.

Un consiglio pratico: testa sempre sotto carico normale e sotto stress. Carico normale: 10-20 utenti simultanei per un sito medio. Stress: raddoppia finché non vedi degrado. E annota il punto di rottura.

Ecco un output di esempio k6:

http_req_duration..............: avg=1.2s  min=0.3s  med=1.1s  max=4.5s  90% 2.1s  95% 2.8s
http_req_failed................: 2.00%  ✓ 80  ✗ 3920

In questo caso il 95% risponde entro 2.8 secondi — accettabile per un’API, ma per una pagina web vorremmo sotto 2 secondi. Il 2% di errori è troppo: devi investigare.

Come integrare k6 nella pipeline CI/CD?

Eseguire test di performance ogni volta che fai deploy è il modo migliore per evitare regressioni. k6 si integra con GitHub Actions, GitLab CI, Jenkins. Noi di Meteora Web lo facciamo per ogni progetto che rilasciamo. Ecco un esempio di workflow GitHub Actions:

name: Load test
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run k6 test
        uses: grafana/k6-action@v0.3.0
        with:
          filename: tests/load.js
          flags: --vus 10 --duration 30s 

Attenzione: nel tuo ambiente CI non testare il server di produzione! Usa un ambiente di staging. E imposta delle soglie (thresholds) per far fallire il pipeline se le performance peggiorano.

Errori comuni da evitare nei test di performance

1. Testare solo in locale. La rete locale ha latenza zero. Devi testare su un server remoto o su un ambiente che simuli la distanza dei tuoi utenti.

2. Dimenticare il database. Molti test ignorano le query. Se il tuo sito fa 100 query per pagina, sotto carico il database collassa. Usa strumenti come k6/x/dbi o monitora il carico DB.

3. Non testare le risorse statiche. k6 può simulare anche il caricamento di immagini e CSS se usi k6/browser (modalità browser). Per test più reali, usa il modulo browser di k6.

4. Ignorare i limiti di sistema. Aprire porte, file handle, connessioni di rete. Assicurati che il tuo sistema operativo permetta abbastanza connessioni simultanee.

Cosa fare adesso

1. Installa k6 sul tuo computer locale: brew install k6 (Mac), choco install k6 (Windows), o scarica il binario da k6.io.
2. Scrivi un test semplice per la homepage del tuo sito. Esegui con 10 utenti per 30 secondi. Guarda i tempi di risposta.
3. Imposta soglie nel test: ad esempio thresholds: { http_req_duration: ['p(95)<2000'] }. Così se il 95° percentile supera 2 secondi, il test fallisce.
4. Integra il test nel tuo deploy con GitHub Actions o GitLab CI. Fallo fallire prima che il codice arrivi in produzione.
5. Leggi la documentazione ufficiale: k6 docs e Artillery docs. Noi le consultiamo ogni giorno.

Non aspettare che un collo di bottiglia ti faccia perdere un cliente. Inizia oggi.

Per approfondire l’intero processo di testing, leggi la nostra guida madre: Testing del Software: Piramide, Automazione e Strategie per Codice che non ti fa Perdere Sonno.