My Blog Is Under Siege

I have been interested in seeing how well my blog would do under heavy load. In the back of my mind I was worried about an article getting really popular and taking my blog down, so I decided to see how much load my server could take before it happened. Obviously being too popular is a good problem to have. This experiment was partly just to give myself fewer excuses to create awesome posts. In case you were interested in the same thing, here is what I did.

But please, use your own blog or website to experiment.:)

Select a load-testing tool

I wanted to survive a fairly heavy load, so I was looking for around three responses per second from the server (which amounts to about 10k requests served per hour.) Anything more and I guess I’ll have to turn people away. ;)

I looked at some load-testing tools that were available for Ubuntu (my home machine), and siege seemed to be the easiest to install and use. Installing was as simple as:

sudo apt-get install siege

Siege comes with a man page and some basic examples. There are a lot of neat options, but I didn’t want to spend too much time on load-testing. One of the best things about this tool is that it tells you that it’s “preparing users for battle” and laying siege to the server, which is just fun.

Initial trials

I started experimenting by hitting the home page with fifteen concurrent users, but this caused a bunch of problems. This means that fifteen people are trying to hit the same page, and whenever they get a response (whether success or failure) they try to get the same page again. I then opted for starting at the minimum and scaling upward.

> siege -c 1
Transactions:               1668 hits
Availability:              98.52 %
Elapsed time:            1973.58 secs
Data transferred:          31.79 MB
Response time:              0.51 secs
Transaction rate:           0.85 trans/sec
Throughput:             0.02 MB/sec
Concurrency:                0.43
Successful transactions:        1692
Failed transactions:              25
Longest transaction:            6.86
Shortest transaction:           0.19

I let this one run for awhile because I thought it would eventually time out and I didn’t want to lose the statistics. But it turns out that whenever you terminate the program with Ctrl+C, the statistics are automatically displayed. What this snippet doesn’t show is that hitting the specified URL will cause two redirects, one to and then one to This ate up quite a bit of time. So my next experiment was to hit the blog index page directly and see how that affected the response times. Also, I upped the concurrent users a bit.

> siege -c 2
Transactions:                    113 hits
Availability:                 100.00 %
Elapsed time:                  83.34 secs
Data transferred:               6.38 MB
Response time:                  0.95 secs
Transaction rate:               1.36 trans/sec
Throughput:                     0.08 MB/sec
Concurrency:                    1.28
Successful transactions:         113
Failed transactions:               0
Longest transaction:            1.72
Shortest transaction:           0.82

Still seems alright, so I added another user.

> siege -c 3
Transactions:                205 hits
Availability:              98.56 %
Elapsed time:             123.74 secs
Data transferred:          11.57 MB
Response time:              1.16 secs
Transaction rate:           1.66 trans/sec
Throughput:             0.09 MB/sec
Concurrency:                1.93
Successful transactions:         205
Failed transactions:               3
Longest transaction:            6.26
Shortest transaction:           0.82


Now I see the first inklings of failure at around three users at a time. I was also hitting the blog from different pages in a browser, and the responses seemed reasonable. At the time, my index page was the last three posts in their entirety, which was pretty big. So I next decided to see what the transaction rate was for an individual post. I figured that this would most closely resemble what happens when someone links to a post.

> siege -c 5
Transactions:                320 hits
Availability:             100.00 %
Elapsed time:              95.16 secs
Data transferred:          13.83 MB
Response time:              0.95 secs
Transaction rate:           3.36 trans/sec   *** this gives me a warm fuzzy feeling
Throughput:             0.15 MB/sec
Concurrency:                3.19
Successful transactions:         320
Failed transactions:               0
Longest transaction:            3.09
Shortest transaction:           0.76


I was pretty excited to see that I could handle about over three transactions per second without any drops, which was my initial goal.

For some reason, the WordPress stats plugin still causes my server to come to a standstill for about thirty seconds, so I think I will rely on Google Analytics in the future for seeing how many people are visiting. It’s not real-time, but gets the job done for analyzing visitor patterns and seeing what else people might be interested in based on their search queries.

Have you tried load testing your apps or blogs? What were the results? What were your favorite tools? You should post in the comments section!

Categories: main

« Interesting Links, Nascent Thoughts Myers-Briggs - ENTP »