🧪 Stress Test in Informatica: Cos’è, A cosa serve e Come si fa

Pubblicato da

  


In ambito informatico, uno dei modi più efficaci per garantire la stabilità e affidabilità di un sistema è sottoporlo a un stress test. Che tu stia sviluppando un’API, gestendo un e-commerce, o distribuendo un'applicazione in cloud, sapere come il tuo sistema si comporta sotto carico estremo è cruciale.

In questo articolo scoprirai:

  • Cos’è uno stress test informatico

  • Qual è la differenza con altri test di carico

  • Perché è importante

  • Come si fa uno Stress Test

  • Strumenti per lo Stress Test

  • Come si configura un test con strumenti reali (JMeter, Locust, k6)

  • Esempi pratici e interpretazione dei risultati

🔗 Ti piace Techelopment? Dai un'occhiata al sito per tutti i dettagli!

✅ Cos’è lo Stress Test in Informatica

Uno stress test è un tipo di test prestazionale che mira a valutare la resilienza di un sistema portandolo oltre il suo carico massimo previsto. Serve a capire come e quando il sistema fallisce, in modo da poter intervenire prima che accada in produzione.

In altre parole: quanto riesce a sopportare prima di cedere?

🧠 Obiettivi principali:

  • Verificare il comportamento del sistema in condizioni estreme

  • Scoprire limiti di scalabilità e colli di bottiglia

  • Individuare punti di rottura (crash, timeout, errori)

  • Testare la capacità di recupero dopo un fallimento


🔍 Differenze con altri tipi di test

Tipo di Test Descrizione
Load Test Misura le prestazioni sotto un carico previsto o leggermente superiore
Stress Test Porta il sistema oltre i limiti per valutare come si degrada o fallisce
Spike Test Simula improvvisi picchi di traffico
Soak Test Verifica la stabilità sotto carico prolungato nel tempo


🧠 Perché fare uno Stress Test

Fare uno stress test significa anticipare i problemi che potrebbero verificarsi in condizioni critiche:

  • Prevenire crash durante eventi ad alto traffico (es. Black Friday, lanci di prodotto)

  • Verificare la tenuta dei server in caso di attacchi DDoS o picchi imprevisti

  • Assicurarsi che le code di messaggi, le cache o i database non si saturino

  • Dimostrare la scalabilità dell'app (quanto cresce il carico che può gestire)

  • Identificare memory leak, errori di concorrenza, malfunzionamenti di rete


⚙️ Come si fa uno Stress Test: Passaggi chiave

1. 🎯 Definizione degli obiettivi

  • Cosa voglio testare? (es. API REST, backend, sito web)

  • Quali sono i limiti attesi? (es. 10.000 richieste al minuto)

  • Quali metriche devo monitorare? (es. tempo di risposta, utilizzo CPU, errori 5xx)

2. 🧪 Preparazione dell'ambiente di test

  • Usare un ambiente di staging (simile al production ma isolato)

  • Avere strumenti di monitoraggio attivi (Grafana, New Relic, Prometheus)

  • Impostare log dettagliati, alert, e snapshot automatici

3. 🛠️ Simulazione dello stress

Utilizzando strumenti di test, si generano richieste al sistema in modo progressivo o esplosivo:

  • Aumento graduale fino al limite teorico

  • Spike improvvisi (es. da 0 a 5.000 utenti in 1 minuto)

  • Persistenza prolungata del carico massimo

4. 📊 Monitoraggio dei risultati

Le metriche più importanti da osservare:

  • Tempo medio di risposta

  • Percentuale di errori

  • Tasso di throughput (richieste al secondo)

  • Utilizzo risorse (CPU, RAM, banda, disco)

  • Stabilità del sistema (crash, timeout, blocchi)

5. 🔁 Analisi e ottimizzazione

Se il sistema fallisce (ed è normale che succeda), occorre:

  • Analizzare i log di errore

  • Individuare cause primarie del collasso

  • Ottimizzare codice, configurazioni, infrastruttura

  • Ripetere il test finché il sistema non regge un carico accettabile


🧰 Strumenti per lo Stress Test

Ecco alcuni degli strumenti più usati per fare stress test:

🔸 Apache JMeter

  • Gratuito, open-source

  • Supporta test HTTP, database, SOAP, FTP, TCP, etc.

  • Ottimo per testare API RESTful o siti web

🔸 Locust

  • Basato su Python, molto flessibile

  • Definizione degli scenari in codice

  • Ottimo per test moderni e dinamici

🔸 Gatling

  • Basato su Scala

  • Report grafici dettagliati

  • Efficiente per test di lunga durata

🔸 Artillery

  • Tool moderno da riga di comando (Node.js)

  • Facile da integrare in CI/CD (GitHub Actions, GitLab CI)

🔸 k6 (di Grafana)

  • Test basati su script JavaScript

  • Ottimo per integrazione DevOps e pipeline


💡 Esempio Pratico con k6

Scenario:

Un’azienda vuole testare un’API /products che normalmente serve 1.000 richieste al minuto. Si vuole sapere fino a che punto regge prima di iniziare a rispondere con errori o rallentamenti eccessivi.

📦 Requisiti:

Nessuna installazione di runtime esterno (come Java o Python): k6 è un binario standalone scritto in Go.

Può essere installato tramite:

File k6.js:

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

export let options = {
  stages: [
    { duration: '2m', target: 100 },   // aumenta a 100 utenti
    { duration: '5m', target: 500 },   // stress costante a 500 utenti
    { duration: '1m', target: 0 },     // ramp-down
  ],
};

export default function () {
  let res = http.get('https://api.azienda.it/products');
  check(res, {
    'status è 200': (r) => r.status === 200,
    'tempo < 500ms': (r) => r.timings.duration < 500,
  });
}

▶️ Avvio del test:

k6 run k6.js

Monitoraggio:

  • Se oltre 400 utenti iniziano a generare errori 503 → possibile limite della capacità del server

  • Se i tempi di risposta superano i 2 secondi → necessario ottimizzare il database o aumentare risorse


🧪 Esempio Pratico con Apache JMeter

🔧 Scenario:

Vogliamo stressare un endpoint HTTP (https://api.azienda.it/products) per simulare 1.000 utenti simultanei, ognuno dei quali effettua richieste in loop.

📦 Requisiti:

  • Apache JMeter installato (download qui)

  • Java installato

  • UI grafica JMeter oppure modalità non-GUI per ambienti server

▶️ Configurazione in JMeter (via GUI):

1. Thread Group

Elemento centrale che definisce il carico del test.

  • Number of Threads (users): 1000
    → Simula 1000 utenti virtuali.

  • Ramp-Up Period (in secondi): 60
    → Significa che JMeter distribuirà l’avvio dei 1000 utenti su 60 secondi.
    Se 1000 utenti in 60 secondi, ne avvia ~16,6 al secondo.
    Scopo: evitare che tutto il carico parta nello stesso istante.

  • Loop Count: 10
    → Ogni utente eseguirà 10 volte la sequenza di richieste (nel nostro caso, chiamata a /products).
    Se vuoi un carico infinito per un certo tempo, puoi usare forever.

2. HTTP Request Sampler

  • Method: GET

  • Path: /products

  • Server: api.azienda.it

3. Listeners

  • Summary Report, View Results Tree, Aggregate Report
    → Per analizzare tempi medi, throughput, errori.

4. Assertion (opzionale ma utile):

  • Verifica che il Response Code sia 200

  • Imposta un tempo massimo di risposta accettabile (es. < 500ms)

▶️ Esecuzione da riga di comando (modalità headless):

jmeter -n -t stress_test.jmx -l result.jtl -e -o report/

Otterrai un report HTML completo nella cartella report/.

📊 Analisi:

Nel report HTML generato troverai:

  • Tempo medio di risposta

  • Percentuale di errori

  • Throughput (richieste/sec)

  • Percentili di risposta (es. 90°, 95°)


🐍 Esempio di Stress Test con Locust

🔧 Scenario:

Simuliamo 500 utenti concorrenti che navigano su un sito e chiamano un endpoint /login e poi /dashboard. Ogni utente ripete il ciclo con pause randomiche.

📦 Requisiti:

  • Python 3

  • Installazione di Locust:

pip install locust

📄 File locustfile.py:

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 3)  # tempo di pausa tra le richieste

    @task(1)
    def login(self):
        self.client.post("/login", json={"username": "test", "password": "1234"})

    @task(2)
    def dashboard(self):
        self.client.get("/dashboard")

▶️ Avvio del test:

locust -f locustfile.py --host=https://www.azienda.it

Poi visita http://localhost:8089 per accedere all'interfaccia web di Locust.

🧪 Esegui lo stress test:

  • Imposta:

    • Numero di utenti: 500

    • Rate di spawn: 50 utenti/sec

  • Avvia e osserva i grafici in tempo reale:

    • Tempo medio di risposta

    • Tasso di errori

    • Throughput

    • Percentili di latenza


🆚 JMeter vs Locust (rapido confronto)

Caratteristica JMeter Locust
Linguaggio XML/UI Python
Curva di apprendimento Medio-bassa Media (richiede un po’ di codice)
Scalabilità Ottima (modalità distribuita) Ottima (può scalare con più workers)
Interfaccia Grafica e CLI Web UI e CLI
Integrazione DevOps Facile con CLI Ottima in pipeline CI/CD


🧠 Considerazioni Finali

✅ Cosa monitorare:

  • Tempo medio di risposta

  • Percentuali di errori HTTP (es. 500, 503)

  • Utilizzo CPU/RAM/server

  • Saturazione database, code, servizi downstream

⚠️ Cosa evitare:

  • Non fare test su ambiente di produzione senza controllo

  • Evita dati reali durante test distruttivi

  • Controlla i costi se usi risorse cloud (es. istanze temporanee)

  • Documentare ogni fase per tracciare miglioramenti nel tempo


📘 Conclusione

Lo stress test in ambito informatico è un processo indispensabile per costruire sistemi resilienti, in grado di affrontare situazioni impreviste senza collassare.
Farli regolarmente permette non solo di individuare punti deboli, ma anche di costruire fiducia nei clienti e garantire continuità del servizio in momenti critici.



Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment