Load testing your web application efficiently

Hi,

Truly execute load testing is the only way to show your web application’s capacity and to see how many concurent users your server can afford in real world.
I still remember when people use Jmeter or it’s wrapper (like blazemeter.com) to execute load testing. We have pretty much more choice now, and in this post I’ll introduce to you 2 free & opensource tool written in Go and promised to be very fast and efficient (network and CPU)

1/ Vegeta ( Github )

Visit the documentation for the installation instruction. For example, in macOS, execute this:

$ brew update && brew install vegeta

This is my favorite tool now. It offers us a lot of options like:
+ Number of cpu to consume
+ Number of requests
+ Number of requests per second (concurrency)
+ Number of redirects to follow
+ Enable http2 or not

It also provide convenient report: JSON / CSV / Plot HTML (see screenshot below)

$ echo “GET http://localhost/” | vegeta attack -duration=5s | tee results.bin | vegeta report
$ cat results.bin | vegeta report -reporter=plot > plot.html

Below screenshot show a test with 200 requests per second, duration is 30 seconds, max open connections is 10000 (default)

Report shows facts:
+ 99.9% successful responses (with 2xx status code)
+ 0.1% failed with status code 500 & 525
+ Average latency time: 117ms; Max latency time: 1.2s

Vegeta also has a lot of libraries (> 9000 libs), which add-up a lot of feature for our need!! ( https://godoc.org/github.com/tsenart/vegeta/lib )

2/ hey ( Github )

Install hey via 1 command on macOS:

$ brew update && brew install go && go get -u github.com/rakyll/hey

.. We’d better read the installation instruction for up-to-date guide: https://github.com/rakyll/hey#installation

Using hey is as easy as cake:

$ hey -h2 -n 5000 -c 100 https://anyHTTP2Website.com/

• -h2: Using http2 client request
• -n: Number of requests to run
• -c: Number of concurrent requests

• 100% successful requests –> running OK with 100 concurrent users is good.
• Response time histogram showed ~50% requests with 1s latency –> GOOD!

3/ Watching server

Usually, before and after executing load testing, we need to measure our server configuration to see what we should configure and what can be improved.
+ Network threshold configuration
+ Web server configuration (nginx, php-fpm…)
+ CPU loads, memory consumption

Note: If you have firewall running in your server, you need to whitelist your machine ip address which you’re using to executing load test, since it will mimic a very large of concurrent requests.

4/ Conclusion

I always say to my co-workers to use the best tools flexibly to get things done. We’d better do!
See you in our next post!

Bonus: Here’s a good list of HTTP(s) benchmark tool ( https://gist.github.com/denji/8333630 )