There’s just one issue with getting said data: other people’s data doesn’t always fit my case, and while there are tons of good benchmarking software out there, they tend to be complicated to install and learn. This is where Siege comes in.
Siege is a simple benchmarking app that simply runs on the terminal. You throw it a URL (and some optional configuration), and it throws you numbers. Like this:
Now, before I get sexy with Siege, first I need to figure out if Smartypants is even an issue in the first place. I’ve talked about Cachegrind before — a part of Xdebug, it allows me to see where PHP spends its time on a script. If Smartypants were an issue, it’d show up as a time-consuming process.
Let’s take a look. I visited my homepage, and passed the results to webgrind, a web front-end, and…
Okay, it’s clearly an issue: it’s taking more time (e.g. has a higher “Cost”) than pretty much everything else in the script. It’s even slower than Kirby’s Markdown processing!
While this tells me that Smartypants needs attention, it doesn’t guarantee that it’s an issue. A lot more happens on a server than PHP parsing. And I need a way to measure and compare whatever improvements I make.
Some people try to measure script execution times, but those vary too much, and don’t simulate a server under pressure.
Installing siege is easy. People on Ubuntu can pretty much just do:
sudo apt-get install siege
If you’re on OS X or just want to install manually, you can also try the instructions here. In a nutshell, get the code, extract it, open the folder in a terminal, and do the usual
./configure && make && make install on it.
Now you can call up Siege straight from the terminal whenever you want!
Time to figure out just how bad Smartypants affects my code.
Launch the Siege!
I’ll start by SSHing into my server to start the test. Yes, the same server where the site is hosted — simply because I don’t want network latency to be an issue. I only want to see how well my code is performing.
From there, it’s a simple call to siege:
siege -i -b -t1M r7.web.id
This will create 15 clients (by default) to bombard my site. It’ll try to get a response and immediately make another request afterwards… Over and over. It will last for one minute. It’ll only hit my homepage, although there are options to give it a list of URLs to hit instead. My site is mostly uniform, and I expect most visitors to stay on my homepage, so this shouldn’t be a problem.
I flip Smartypants to on. One minute later, I get my results.
Transactions: 2122 hits Availability: 100.00 % Elapsed time: 59.40 secs Data transferred: 20.03 MB Response time: 0.42 secs Transaction rate: 35.72 trans/sec Throughput: 0.34 MB/sec Concurrency: 14.94 Successful transactions: 2122 Failed transactions: 0 Longest transaction: 2.21 Shortest transaction: 0.09
This is all really nifty data. I’m simulating 15 users constantly refreshing as fast as they can. During the span of one minute, they managed to load the page 2122 times.
The most important number is Response Time. This shows how long, on average, the server took to reply to a user HTTP request (when the server is at load, as this simulates). 420 milliseconds is unacceptably long for me. It means your average user has to wait at least 420ms before getting the first byte from the server, and that sucks. We’ll need to take a look at that.
(Note, however, that this is in stressed conditions. The Shortest transaction is only 90ms, which is just fine.)
Glancing at the other numbers, we look fine. The Throughput looks low, but that’s because our bottleneck lies in code execution, not bandwidth. If I were using Siege from a remote server, then this would be affected by my bandwidth. I also don’t have any Failed transactions, which is a good thing.
Right. Let’s do the comparison. I’ll switch Smartypants off.
Transactions: 3318 hits Availability: 100.00 % Elapsed time: 59.72 secs Data transferred: 30.77 MB Response time: 0.27 secs Transaction rate: 55.56 trans/sec Throughput: 0.52 MB/sec Concurrency: 14.97 Successful transactions: 3318 Failed transactions: 0 Longest transaction: 1.65 Shortest transaction: 0.07
Right off the bat, we can see that the server managed to serve 50% more transactions overall. The response time dropped from 420ms to 270ms — a huge difference.
I now know that Smartypants accounts for a lot of my site’s processing. Well, Smartypants is basically just a function that runs on text — there’s no reason for it to run every time someone views a page, is there? It only needs to process text once.
Right! It’s time to turn on Caching.