Come installare Siege su Ubuntu 20.04 LTS

Installare Siege su Ubuntu 20.04 LTS senza complicarsi la vita

Siege è uno strumento essenziale quando devi capire se un servizio web regge un certo livello di concorrenza, se la TTFB sale troppo sotto carico o se un reverse proxy sta mascherando un collo di bottiglia sull’origin. Su Ubuntu 20.04 LTS l’installazione è semplice, ma conviene farla con criterio: prima verifichi i repository disponibili, poi installi il pacchetto, infine validi che il binario risponda e che il test che stai per lanciare sia realistico rispetto all’ambiente.

In pratica, Siege non serve a “fare rumore” sul server: serve a misurare. Se lo usi male, ottieni solo errori e numeri poco utili. Se lo usi bene, ottieni una fotografia abbastanza chiara di cosa succede quando aumenti richieste, durata e concorrenza. Questa guida parte dall’installazione su Ubuntu 20.04 LTS e arriva fino a un uso minimo ma corretto, con esempi replicabili e verifiche immediate.

Verifica del pacchetto nei repository Ubuntu

Su Ubuntu 20.04 LTS Siege è normalmente disponibile nei repository ufficiali, quindi nella maggior parte dei casi non serve aggiungere PPA o repository esterni. Questo è un vantaggio concreto: meno superficie di rischio, meno problemi di compatibilità e meno manutenzione futura. Prima di installare, puoi verificare che il pacchetto sia presente e vedere da dove verrebbe preso.

Il controllo più rapido è questo:

apt-cache policy siege

Se il pacchetto è disponibile, vedrai una versione candidata e l’origine del repository. Se il comando non restituisce nulla di utile, aggiorna prima l’indice dei pacchetti. In un ambiente appena installato o non aggiornato da tempo, questa è una verifica da fare sempre prima di trarre conclusioni.

Per aggiornare l’elenco dei pacchetti disponibili:

sudo apt update

Dopo l’update, ripeti il controllo. Se il pacchetto compare, puoi procedere senza introdurre sorgenti esterne. Se non compare, il problema non è Siege: è la configurazione dei repository del sistema, e va risolta prima di andare oltre.

Installazione con apt

L’installazione standard è diretta e non richiede dipendenze particolari oltre a quelle gestite da apt. Il comando è il seguente:

sudo apt install siege

Durante l’installazione apt risolve automaticamente le librerie richieste. Se stai operando su un server minimale, è una buona idea annotare la versione installata, perché nei test di performance anche differenze minime nel comportamento del client possono cambiare i risultati se confronti sessioni fatte a distanza di tempo.

Per verificare che il pacchetto sia stato installato correttamente, usa uno di questi controlli:

siege --version

oppure:

dpkg -l siege

Il primo ti mostra la versione del binario, il secondo conferma che il pacchetto è presente nel database locale di dpkg. Se il comando `siege --version` fallisce ma `dpkg -l siege` mostra il pacchetto installato, allora il problema è nel PATH o in una installazione parziale; in quel caso conviene controllare dove si trova il binario con:

command -v siege

In condizioni normali il risultato atteso è un percorso come `/usr/bin/siege`.

Che cosa installi davvero e perché conta

Siege è un client di benchmark HTTP/HTTPS. Non sostituisce strumenti di osservabilità lato server, non misura direttamente CPU, I/O o saturazione della rete, e non ti dice da solo se il problema è applicativo o infrastrutturale. Quello che fa bene è generare richieste in modo ripetibile e produrre un report sintetico con tempi medi, throughput, errori e durata del test.

Questo significa che il suo valore cresce quando lo affianchi a log web server, metriche del sistema e, se c’è, telemetry applicativa. Se lanci Siege senza guardare almeno i log di Nginx, Apache o dell’app, rischi di sapere che qualcosa va male senza capire dove. La sequenza corretta è sempre la stessa: definisci il target, fai un test breve, osservi i sintomi, poi allarghi il carico.

Un dettaglio pratico: su ambienti condivisi o staging con dati reali, è facile sottovalutare l’impatto di un test “piccolo”. Anche 20-30 connessioni simultanee possono attivare rate limit, WAF, cache miss o code sul backend. Per questo è utile partire con un profilo conservativo e aumentare gradualmente.

Primo test controllato

Il primo obiettivo non è stressare il sistema, ma verificare che Siege sia operativo e che il target risponda come previsto. Usa un URL stabile, meglio se una pagina statica o un endpoint semplice che non faccia dipendere il risultato da login, sessioni o contenuti dinamici variabili.

Esempio minimale:

siege -c 5 -t 30S http://example.com/

Qui stai chiedendo 5 utenti concorrenti per 30 secondi. È un test corto, sufficiente per capire se il comando funziona e se il target restituisce risposte coerenti. Se il sito usa HTTPS, la forma è identica:

siege -c 5 -t 30S https://example.com/

Quando Siege parte correttamente, il report finale include richieste totali, transazioni al secondo, tempo di risposta medio, disponibilità e percentuale di errori. Il significato operativo è questo: se la disponibilità scende o gli errori aumentano già con carico basso, non hai un problema di performance “da tuning fine”; hai un problema di base da chiarire prima di aumentare la concorrenza.

Interpretare il report senza farsi ingannare

Il report di Siege è utile, ma va letto con disciplina. Un throughput alto non vale molto se la percentuale di errori cresce o se il tempo di risposta medio si allunga in modo non lineare. Allo stesso modo, un test breve può sembrare perfetto mentre un test più lungo mostra saturazione di cache, esaurimento di connessioni al backend o degradazione del database.

Le metriche che guardo per prime sono tre:

• error rate, perché è il segnale più diretto di fallimento;
• tempo medio di risposta, perché indica se la latenza cresce sotto carico;
• transazioni al secondo, perché ti dice se il sistema scala o si pianta su un plateau.

Se il test è su un’app con backend PHP, Node, Python o Java, non fermarti al numero finale. Incrocia i risultati con i log del web server e con eventuali metriche di sistema. Se vedi errori 502 o 504, il problema può essere nel proxy o nel backend. Se vedi timeout ma il processo applicativo è vivo, spesso il collo di bottiglia è nel database o nel pool di worker.

Un errore comune è confondere il limite del client con il limite del server. Se il tuo host da cui lanci Siege è piccolo o già carico, potresti saturare prima il client del target. In quel caso il benchmark misura la macchina che genera il carico, non quella che lo riceve. Per questo è sensato eseguire il test da un nodo dedicato o comunque monitorare anche il sistema che lancia Siege.

Parametri utili da conoscere

Siege offre una serie di opzioni che diventano importanti non appena il test smette di essere banale. Le più usate sono `-c` per la concorrenza, `-t` per la durata, `-f` per leggere un elenco di URL da file e `-i` per simulare richieste casuali da una lista. In molti casi, il test serio non è un singolo URL ripetuto, ma un mix di endpoint che rappresenta il traffico reale.

Esempio con file di URL:

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

Il file `urls.txt` contiene un URL per riga. Questa modalità è utile quando vuoi simulare una navigazione mista, per esempio home, pagina prodotto, ricerca e un endpoint API. Il vantaggio è che il test assomiglia di più all’uso reale rispetto a un solo endpoint ripetuto all’infinito.

Se vuoi aggiungere autenticazione o header specifici, Siege supporta anche opzioni più avanzate, ma qui conviene restare sul pratico: prima fai funzionare il test base, poi introduci complessità solo se serve davvero alla tua analisi. Nei test di performance, ogni variabile aggiunta rende più difficile capire quale componente stia influenzando il risultato.

Uso con HTTPS, virtual host e reverse proxy

Su ambienti moderni è normale testare un URL dietro HTTPS, CDN o reverse proxy. In questi casi l’interpretazione del risultato cambia: potresti stare misurando il comportamento dell’edge, della cache o del proxy più che dell’applicazione. Questo non è un difetto, ma va dichiarato nel test. Se il tuo obiettivo è il backend, devi progettare il percorso per arrivarci senza falsare i numeri.

Per esempio, se hai Nginx davanti a PHP-FPM, un test sulla home pubblica può dirti molto sulla cache e poco sul backend. Se vuoi stressare PHP-FPM, meglio colpire un endpoint non cachabile oppure impostare un bypass controllato. Se invece vuoi verificare la resilienza dell’edge, allora il test pubblico ha perfettamente senso.

Con virtual host multipli è importante usare l’hostname corretto, non solo l’IP. Se il certificato TLS o la configurazione del server name non sono allineati, potresti ricevere un comportamento diverso da quello atteso. Un controllo semplice è questo:

curl -I https://tuodominio.example/

Se `curl` fallisce, Siege non ti aiuterà a rendere magico un problema di base. Prima risolvi connettività, DNS, TLS e risposta HTTP, poi fai partire il benchmark.

Log e controlli lato sistema mentre esegui il test

Durante il test, conviene tenere aperti almeno due punti di osservazione: i log del web server e lo stato dei processi. Su Ubuntu 20.04 LTS con systemd puoi controllare i servizi in tempo reale con `journalctl`, oppure guardare i file di log tradizionali se la tua configurazione li usa ancora in modo esplicito.

Esempi utili:

sudo journalctl -u nginx -f
sudo journalctl -u apache2 -f
sudo top
sudo ss -s

Se stai usando PHP-FPM, aggiungi anche il servizio relativo. Se noti code lunghe, worker occupati o errori di timeout nei log, hai una pista concreta. Se invece i log restano puliti ma Siege mostra errori, controlla il layer di rete o eventuali limiti lato firewall, CDN o load balancer.

Questa è la parte che molti saltano: il benchmark da solo non basta. Il valore arriva quando colleghi il numero di Siege a un evento osservabile nel sistema. Senza quel collegamento, il report è solo una tabella con numeri difficili da usare.

Installazione da sorgente: quando ha senso e quando no

In alcuni casi potresti non voler usare il pacchetto della distribuzione, per esempio se ti serve una versione specifica o se il repository del sistema è incompleto. In Ubuntu 20.04 LTS, però, compilare Siege da sorgente ha senso solo se hai un motivo preciso. Altrimenti aggiungi complessità senza guadagno reale.

Se devi verificare rapidamente le dipendenze di build, il percorso corretto è prima capire se il pacchetto ufficiale è sufficiente. Solo in seconda battuta puoi considerare la compilazione. In quel caso, il rischio operativo è maggiore: devi gestire toolchain, librerie di sviluppo e manutenzione del binario installato fuori dal sistema di packaging standard.

Per un ambiente server, il pacchetto apt resta la scelta più pulita. È tracciabile, disinstallabile e coerente con il resto del sistema. Se un giorno devi rimuoverlo, il rollback è immediato:

sudo apt remove siege

Se vuoi anche eliminare configurazioni residue installate dal pacchetto, puoi valutare `purge`, ma solo se sei sicuro di non voler conservare file di configurazione personalizzati. In un contesto di test, spesso non c’è nulla da preservare; in un ambiente condiviso, meglio controllare prima cosa è stato effettivamente modificato.

Un flusso di lavoro sensato per benchmark ripetibili

Se vuoi usare Siege in modo professionale, costruisci sempre lo stesso flusso. Prima definisci l’obiettivo: vuoi misurare latenza, errori o capacità massima? Poi scegli il target corretto: homepage, endpoint API, pagina cachata o endpoint dinamico. Infine stabilisci una baseline e confronta i risultati dopo ogni modifica al sistema.

Una sequenza pratica può essere questa:

1. controlla che il target risponda con `curl -I`;
2. esegui un test breve con bassa concorrenza;
3. leggi report di Siege e log del backend;
4. aumenta un solo parametro per volta;
5. confronta i risultati con la baseline precedente.

Questo approccio evita la classica trappola del “ho cambiato tre cose insieme e non capisco quale abbia migliorato o peggiorato il servizio”. Nei test di carico, la disciplina vale più della potenza del tool. Siege è semplice, ma proprio per questo va usato con metodo.

Un’osservazione utile: se il tuo sito usa cache a più livelli, puoi ottenere risultati molto diversi tra primo e secondo run. Il primo colpo può riempire cache, il secondo misurare solo hit rate e non la reale capacità dell’app. Per confronti seri, devi dichiarare sempre se il test è a cache fredda o calda.

Rimozione pulita e verifica finale

Se hai installato Siege solo per una sessione di verifica o su una macchina di lavoro temporanea, rimuoverlo è semplice. Prima controlla che non ci siano script o automazioni che lo usano ancora, poi disinstalla il pacchetto con apt. La verifica finale consiste nel confermare che il binario non sia più presente.

sudo apt remove siege
command -v siege

Se `command -v siege` non restituisce alcun percorso, la rimozione è andata a buon fine. Se invece il binario è ancora presente, probabilmente hai una copia installata manualmente in un percorso non gestito da apt, e va rimossa separatamente. In quel caso il controllo del PATH è il primo passo, non l’ultimo.

Su Ubuntu 20.04 LTS la strada più solida resta questa: repository ufficiali, installazione con apt, test breve di validazione, poi uso controllato con osservabilità attiva. È un tool piccolo, ma utile solo se inserito in un processo serio di misurazione. Se lo tratti come un generatore casuale di traffico, ottieni numeri. Se lo tratti come uno strumento di analisi, ottieni indicazioni operative davvero spendibili.