Here are 3 ways to help you load test your websites

Load testing is important because you want to figure out where your performance bottlenecks are, you want to populate New Relic with data, and generally you just want to get back to management and show them a spreadsheet pointing bottom right why you need a bigger server (or development time).

It’s essentially pointing machines at websites to load pages. Or hurling data at API endpoints.

There are a LOT of ways you can do this, but I’ll talk about 3 in order of ease:

• https://loader.io
• siege
• goad

Loader.io by Sendgrid

https://loader.io

Nifty little tool. Same people who run the transactional mail service. There’s a free tier that will get you 10,000 clients / test, 1 target host, 1 minute tests, and max 2 urls per test. For budding load testers, this is neat. Super simple. Web based.

You would need to verify that you own the domain by either setting a DNS record or uploading a file to the FTP server as - understandably - Sendgrid doesn’t want to be responsible for DDoSing anyone.

The results will be two graphs. Green for how many clients are on the site at any given time (right hand side of the graph for the scale), while blue for response time. You want to keep blue flat and green climbing as time goes on. That means the site holds its own at increasing amounts of clients.

If chart is like the one in the image below, that means that as the server gets more concurrent visitors, it begins to struggle, ie not scalable.

The Good:

• super simple
• has free tier
• web based

The hard part

• you will need to verify you have access to the server

siege

siege

Hat tip to Patrick Garman for this one.

It is medium difficulty to use / interpret of the three. On Mac, this is how you install it. Make sure to have Homebrew before doing so.

brew install siege

After that you can configure siege:

siege.config

Or if that command complains there’s already one, just open the ~/.siege folder, and have a read through the siege.conf file.

To actually test a url, do this:

siege -c 25 -t1m -v https://foobar.dev

This will start the siege, and you will get a rolling list of URLs it’s hitting, status codes, etc.

After siege is done, it will give you a summary of what just happened.

Caveats: siege uses your data connection to talk to the sites, so don’t do this tethered to your mobile phone. It can also bring down your / your company’s internet connection because you’ve saturated it.

IMPORTANT: Please please only point siege at servers you own / control / have permission to load test.

The good

• forever free
• pretty robust

The hard part

• uses your own internet connection
• you need to be comfortable with the command line
• may hang on some systems when lifting the siege (is fixed in version 4.0.4, see https://github.com/JoeDog/siege/issues/66)

Goad

https://goad.io/ / https://github.com/goadapp/goad

For when you REALLY hate your server and want to kill it.

Hat tip to Chuck Mac for this gem.

It’s like siege, instead the requests are originating from AWS Lambda. It takes a while to set up, as you need to hunt around for the binary (it’s in the GitHub repo’s "releases" tab).

It’s advanced, because you need to have an AWS account, access to the console, have an IAM user, grant that user suitable permissions to set up the lambda function and execute it and get it to save in the SQS. The steps generally involve:

• making sure you have access to AWS console
• creating a new user for the machine
• grabbing the AWS credentials for that user in a csv file
• assigning permissions to that user (see #4)
• getting the aws-cli on your computer (involves pip)
• configuring the aws credentials, making sure the region is correct too

Assuming everything is set up correctly, you can run it with the command below. If things aren’t set up correctly, it will tell you.

goad -n 0 -c 5 -t 20 --json-output="/Users/<yourusername>/goad.json" https://foobar.dev

See the help (goad --help) on what they mean. This will produce output on the terminal, and save the data in a json file too.

Important: Seriously, only point this at servers you control / have permission to load test.

The Good

• you can seriously do some load testing with this one
• AWS managed, fine grained permission controls, so you know who did what, where and why
• you can create an ini template and then use that to run it

The hard

• it’s AWS, so not the most straightforward to set up
• haven’t found a way to test multiple urls on the same server yet

Conclusion

At this time I’ll be using siege for this specific project I’m working on currently.

Photo by Samuel Zeller from Unsplash