Install Siege Benchmarking Tool on Ubuntu 22.04 LTS
You want to throw some real‑world load at your web server and see how it behaves under pressure. This short guide shows exactly how to get Siege up and running on Ubuntu 22.04, plus a couple of tips that saved me from chasing phantom “connection timed out” errors.
Quick sanity check – why Siege?
Siege is a lightweight command‑line load generator that can hammer a single URL or an entire site with multiple concurrent users (workers). It’s not a full‑blown testing suite like JMeter, but for quick performance snapshots it does the job without pulling your system into a memory‑eating frenzy.
Prerequisites
- A fresh Ubuntu 22.04 installation (or any recent LTS) with sudo access.
- An HTTP service listening on a reachable address – even localhost works for local testing.
I’ve seen people stumble after a kernel update because the default firewall blocked outbound connections; make sure your UFW or iptables rules let traffic out on port 80/443 before you start.
Step 1: Install the package from the official repo
sudo apt update
sudo apt install siege -y
apt pulls the latest stable version that Ubuntu ships (2.70 at time of writing). It’s good enough for most cases; if you need bleeding‑edge features, building from source is an option, but it rarely justifies the extra hassle.
Step 2: Verify the installation
siege --version
You should see something like Siege 2.70 (build 2023-07-01). If you get a “command not found” error, double‑check that /usr/bin is in your $PATH.
Step 3: Create a simple test file
echo "http://localhost/" > urls.txt
Siege reads URLs from a file by default. Adding more lines lets you hit multiple endpoints without fiddling with the command line each time.
Step 4: Run a basic benchmark
siege -c10 -t30S -f urls.txt
- -c10 tells Siege to simulate ten concurrent users.
- -t30S limits the test to thirty seconds; you can use M for minutes or H for hours.
- -f urls.txt points to the file we just created.
Why those flags? A short, controlled run prevents your server from getting stuck in a denial‑of‑service loop while you’re still figuring out the right parameters. I once let Siege run unchecked for five minutes with 500 users on a dev box and spent an hour untangling kernel OOM kills.
Step 5: Interpret the output
Siege prints a concise summary at the end:
Transactions: 300 hits
Availability: 100.00 %
Elapsed time: 30.01 secs
Data transferred: 4.56 MB
Response time: 0.12 secs
Transaction rate: 9.99 trans/sec
Throughput: 0.15 MB/sec
Concurrency: 1.20
Successful requests: 300
Failed requests: 0
Longest transaction: 0.45
Shortest transaction: 0.03
Key takeaways:
- Transaction rate shows how many requests per second your server handled under the chosen load.
- Concurrency tells you the average number of simultaneous connections; if it’s much higher than -c, something else (like keep‑alive) is inflating the count.
- Failed requests should stay at zero; any spikes usually indicate a bottleneck or misconfiguration.
Optional tweaks – making Siege more useful
- Enable keep‑alive: Add --keep-alive to keep connections open, which mimics real browsers better.
- Add delay between hits: Use -d5 for a random 0–5 second pause; this prevents your test from looking like a brute‑force attack.
- Output CSV for graphs: siege -c20 -t1M -f urls.txt --csv=report.csv. Import the file into Excel or Google Sheets to spot trends over time.
Common pitfalls
- Missing libssl – older Ubuntu releases sometimes omit libssl-dev, causing Siege to fail on HTTPS URLs. Install it with sudo apt install libssl-dev and rerun.
- Firewall blocking – If you see “Connection timed out” for every request, double‑check that inbound traffic is allowed on the ports you’re testing.
That’s all there is to it. With Siege installed, you can quickly answer questions like “Can my server handle 100 users?” without pulling in a heavyweight framework.