Come installare Siege su Ubuntu 22.04 per test di carico

Installare Siege su Ubuntu 22.04: il punto non è solo il pacchetto, è il metodo

Se devi testare un sito o una API su Ubuntu 22.04, Siege è uno strumento semplice ma ancora utile per fare carico HTTP in modo rapido, senza portarti dietro una piattaforma di load testing più pesante. La parte importante non è “installarlo e basta”: conviene capire subito cosa misura, cosa non misura e come evitare risultati fuorvianti.

Su Ubuntu 22.04 l’installazione è lineare, ma il test serio richiede almeno tre cose: una sorgente pulita, un target ben definito e una lettura corretta delle metriche. Se salti questi passaggi, ottieni numeri impressionanti ma poco utili. E in un test di carico, numeri poco utili sono quasi peggio di nessun numero.

Installazione da repository Ubuntu

Siege è disponibile nei repository ufficiali di Ubuntu 22.04, quindi nella maggior parte dei casi non serve compilare nulla. L’approccio consigliato è usare apt, così hai aggiornamenti gestiti dal sistema e integrazione coerente con il resto dello stack.

Prima aggiorna l’indice dei pacchetti e installa lo strumento:

sudo apt update
sudo apt install siege

Dopo l’installazione verifica che il binario sia presente e che la versione risponda correttamente:

siege --version

Atteso: una stringa con la versione installata e la conferma della build per Ubuntu. Se il comando non esiste, il problema è quasi sempre uno tra repository non aggiornati, installazione fallita o PATH alterato. In quel caso il controllo immediato è:

dpkg -l | grep siege
which siege

Se vuoi una verifica rapida dei file installati, puoi anche ispezionare il pacchetto con dpkg -L siege. Non è un passaggio obbligatorio, ma torna utile quando devi capire dove stanno i file di configurazione o se una reinstallazione ha davvero sistemato il problema.

Perché Siege è utile nei test di carico semplici

Siege nasce per generare richieste HTTP concorrenti verso uno o più endpoint e restituire statistiche essenziali: throughput, tempi di risposta, tasso di successo, errori e durata del test. È una scelta ragionevole quando ti serve un controllo rapido su una web app, un reverse proxy, un bilanciatore o una singola API.

Il suo vantaggio è la velocità operativa: in pochi minuti puoi simulare richieste ripetute su un endpoint e ottenere un quadro grezzo ma utile. Il limite è altrettanto chiaro: non è lo strumento ideale per modellare comportamenti utente complessi, flussi con sessioni articolate o scenari distribuiti multi-regione. Se ti serve quel livello, devi salire di categoria.

In pratica, Siege è valido per rispondere a domande come: “Quante richieste al secondo regge questo endpoint?”, “Il proxy restituisce 502 sotto pressione?”, “La latenza p95 peggiora dopo un certo numero di connessioni concorrenti?”.

Primo test: una URL, concorrenza, durata

Il caso base è un test su una sola URL. La sintassi minima è semplice e leggibile:

siege -c 10 -t 1M https://example.com/

Qui -c 10 imposta 10 client concorrenti e -t 1M fa durare il test un minuto. È un buon punto di partenza, perché ti consente di capire se il target regge un carico moderato senza saturare subito la macchina da cui lanci il test.

Se stai lavorando su una pagina specifica, usa sempre un URL completo. Evita di testare genericamente la home se il collo di bottiglia è altrove: magari l’API lenta è /api/search, non la landing page. Un test ben indirizzato vale più di dieci test rumorosi.

Output tipico da osservare: transazioni completate, tasso di fallimento, tempo medio di risposta e disponibilità percentuale. Se il sito risponde ma i tempi crescono in modo non lineare, la causa può stare nel backend, nel database o in un limite di connessioni del proxy. Se invece compaiono errori immediati, il problema è spesso a monte: DNS, TLS, WAF o origin non raggiungibile.

Usare una lista di URL per simulare traffico più realistico

Siege può leggere un file con più URL, utile quando vuoi distribuire il carico su più endpoint invece di martellare sempre lo stesso percorso. Questo è importante perché molti siti reggono bene la home ma cedono sulle pagine dinamiche o sugli endpoint che toccano il database.

Crea un file, ad esempio urls.txt:

https://example.com/
https://example.com/login
https://example.com/api/status

Poi lancia il test con il file:

siege -c 20 -t 2M -f urls.txt

La verifica da fare dopo non è solo “ha risposto?” ma “quali URL hanno fallito e con quale pattern?”. Se i fallimenti si concentrano su una sola rotta, il problema è locale. Se invece cadono tutte le URL, il collo di bottiglia è probabilmente condiviso: rete, reverse proxy, pool applicativo, database o storage.

Il file di configurazione: quando conviene usarlo

Per utilizzi ripetuti è più pulito definire un file di configurazione, così non devi riscrivere ogni volta le stesse opzioni. Su Siege il file utente è tipicamente ~/.siege/siege.conf. Se la directory non esiste, puoi crearla manualmente.

mkdir -p ~/.siege
cp /etc/siege/siege.conf ~/.siege/siege.conf

Il path esatto può variare in base al pacchetto, quindi il modo corretto di chiudere il dubbio è verificare i file installati con:

dpkg -L siege | grep siege.conf

Nel file puoi regolare parametri come timeout, user-agent e comportamento generale del client. La cosa importante è trattarlo come configurazione operativa, non come un posto dove infilare valori casuali. Se cambi il timeout, annota il motivo: un timeout troppo corto produce falsi negativi, uno troppo lungo nasconde una degradazione reale.

Se devi condividere il file con altri operatori, evita di inserire dati sensibili. In genere non servono segreti per un load test, e comunque non ha senso mettere credenziali in chiaro in un profilo locale se puoi usare token temporanei o ambienti di test dedicati.

Test autenticati: attenzione a cookie, header e sessioni

Molti endpoint utili non sono pubblici: pensiamo a pannelli admin, API con token, aree riservate o dashboard interne. Siege può inviare header personalizzati, ma il punto non è “forzare l’autenticazione” in modo creativo; il punto è riprodurre il comportamento reale con il minimo indispensabile.

Se l’app richiede un bearer token, usa un token di test con privilegi minimi e rotazione prevista. Se usa cookie di sessione, verifica prima quanto dura la sessione e se il test di durata rischia di scadere a metà esecuzione. In molti casi il fallimento apparente è solo una sessione scaduta, non un problema di performance.

Per aggiungere un header, la documentazione del pacchetto e l’help locale sono il riferimento corretto. Se vuoi evitare supposizioni, controlla direttamente le opzioni disponibili sul tuo binario:

siege --help

Questa verifica è più affidabile di un esempio copiato a memoria, perché le opzioni possono cambiare tra versioni o build dei pacchetti distribuiti dalla distro.

Come leggere i risultati senza farsi ingannare

Quando Siege termina, non guardare solo il numero di transazioni al secondo. Il dato utile nasce dall’incrocio di più indicatori: tempo medio di risposta, disponibilità, errori e durata effettiva. Un throughput alto con errori alti non è un successo, è solo un sistema che sta fallendo velocemente.

Tre segnali da interpretare con attenzione:

• Tempo medio basso ma errori crescenti: il sistema risponde finché la coda è corta, poi collassa.
• Tempo medio alto e errori bassi: il sistema regge, ma la latenza è già un problema per l’utente.
• Disponibilità buona ma throughput fermo: probabilmente hai saturato il client o il test non è abbastanza aggressivo.

Per questo conviene correlare i risultati con le metriche del target: CPU, RAM, I/O disco, connessioni aperte, error rate del reverse proxy, saturazione del database e log applicativi. Senza osservabilità lato server, il load test ti dice solo che qualcosa è andato storto, non cosa.

Verifiche lato server prima e dopo il test

Un test di carico fatto bene non si limita a lanciare richieste. Prima del test, registra lo stato del sistema; durante il test, osserva i segnali di saturazione; dopo il test, confronta i valori. Il minimo sindacale su Ubuntu 22.04 è controllare i servizi coinvolti e i log principali.

Esempi pratici:

systemctl status nginx
systemctl status php8.1-fpm
journalctl -u nginx -n 50 --no-pager
journalctl -u php8.1-fpm -n 50 --no-pager

Se il backend è un’API, aggiungi i log applicativi del framework o del container. Se il collo di bottiglia è il database, osserva il numero di connessioni, i lock e i tempi di query. Se il disco è coinvolto, un carico di lettura apparentemente innocuo può diventare un problema di I/O e non di CPU.

Il criterio pratico è questo: se il test di Siege mostra degrado ma i log lato server sono puliti, probabilmente stai guardando il componente sbagliato o non hai abbastanza telemetria. In quel caso la chiusura del gap non è “rifare il test”, ma aggiungere metriche e log coerenti con il percorso della richiesta.

Scenario tipico: test su Nginx dietro PHP-FPM

Uno scenario comune su Ubuntu 22.04 è Nginx davanti a PHP-FPM. In questo caso Siege serve a capire se il limite è sul web server, sul pool PHP o sul database. Un buon test di base è colpire una pagina che esegue logica reale, non un file statico. Se usi solo una risorsa statica, stai testando quasi esclusivamente Nginx e la rete.

Per esempio, se la homepage è completamente cache-abilizzata, il test non ti dice quasi nulla sul comportamento dell’app sotto carico. Meglio una rotta che faccia almeno una query o una chiamata applicativa. Se non hai un endpoint dedicato, crea una pagina di diagnostica nel tuo ambiente di test invece di improvvisare sul prod.

Un pattern utile è partire con concorrenza bassa e aumentare gradualmente:

siege -c 5 -t 1M https://example.com/test
siege -c 10 -t 1M https://example.com/test
siege -c 25 -t 1M https://example.com/test

In questo modo identifichi il punto in cui la latenza sale o compaiono errori. Se il degrado è netto a una soglia precisa, hai un indizio forte su un limite di pool, connessioni o risorse. Se invece il collasso è graduale, il problema è più probabilmente una saturazione distribuita tra più componenti.

Buone pratiche operative prima di lanciare Siege

Un test di carico fatto male può sporcare i risultati e, in alcuni casi, disturbare utenti o sistemi vicini. Prima di lanciare Siege, chiarisci sempre l’ambiente: staging o produzione, finestra temporale, target preciso e rollback se il test deve attivare un cambio temporaneo.

1. Verifica che l’URL sia quello giusto e che il target sia autorizzato al test.
2. Controlla che il client da cui lanci il carico abbia banda e CPU sufficienti.
3. Assicurati di avere metriche lato server attive prima di partire.
4. Se il target è in produzione, avvisa chi presidia il servizio e definisci una soglia di stop.
5. Conserva l’output del test in un file, così puoi confrontarlo in seguito.

Per salvare l’output puoi fare redirect standard e tenere uno storico dei test. Non è glamour, ma è uno dei modi più semplici per confrontare configurazioni diverse nel tempo:

siege -c 10 -t 1M https://example.com/ | tee siege-2026-04-17.txt

Il file risultante non sostituisce i log del server, ma ti dà una traccia ripetibile del test. Se cambi qualcosa nel backend, il confronto tra due esecuzioni è spesso più utile della memoria dell’operatore.

Quando Siege non basta più

Siege è ottimo per test mirati, ma non è lo strumento universale. Se devi simulare utenti con login, flussi multi-step, think time realistico, distribuzione geografica o scenari complessi con più servizi, conviene usare strumenti più adatti al caso. Non è un difetto di Siege: è un limite naturale del suo modello di utilizzo.

La regola pratica è semplice: se ti serve una risposta rapida su un endpoint, Siege va bene. Se ti serve una campagna di load testing completa con metriche avanzate e scenari complessi, usalo al massimo come parte del controllo, non come unico strumento.

In sintesi operativa, su Ubuntu 22.04 l’installazione è banale; la differenza la fa il modo in cui imposti il test, leggi l’output e lo confronti con i segnali del server. Il valore vero non è “ho fatto partire Siege”, ma “ho ottenuto un dato che posso usare per decidere se cambiare configurazione, ottimizzare il backend o aumentare capacità”.