k6 is an open-source tool to conduct advanced load testing of your services. While it have an nice albeit pricy hosted option complete with an UI, the self-hosted option is probably what you will try initially.
Beside simply hammering your endpoints with no or random payloads, k6 can also import dummydata from files and you can setup long running tests with multiple serial or paralell sceanrios. A scenario can include different stages of different load levels. Simply put, it's a powerful and resource efficient tool (do however note that any file you open will be opened in every single user-worker).
The k6 docs has some information on what configurations you should change for running large tests. Unfortunately all of them won't work as stated and there are some additional tools you can use to make it easier on yourself.
First, unless you already got some tool to manage this let's update any outdated tools:
sudo yum update -y
The docs recommends configuring your kernel to maximize network throughput:
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535" sudo sysctl -w net.ipv4.tcp_tw_reuse=1 sudo sysctl -w net.ipv4.tcp_timestamps=1
It also mentions you should increase the resources available to your user (shell session) with ulimit, by using the built in shell command ulimit. On most popular distros you will run into an error doing that, as ulimit is a shell built-in and not an external command. Instead you need to
sudo nano /etc/security/limits.conf and add these lines to it (tab separated):
* soft nofile 250000 * hard nofile 250000
To install k6 on you Amazon Linux 2 instance, run these commands.
wget https://bintray.com/loadimpact/rpm/rpm -O bintray-loadimpact-rpm.repo sudo mv bintray-loadimpact-rpm.repo /etc/yum.repos.d/ sudo yum install k6 -y
With k6 installed you only need your tests on the instance to run them. While you could use git to pull this from a repo, I find it easier to just use scp. So for any tests and json-files with dummy payloads:
scp -i "~/<path_to_cert_for_ec2>.pem" ./<path_to_local_file>.js ec2-user@ec2-XX-XX-X-XXX.region.compute.amazonaws.com:<path_to_remote_file>
That's it, now we can run k6... almost! When starting any long running command (that's not a daemon) you should run it inside a screen-session. This way, if your local computer crashes or your SSH-session closes the command you were running will still be there when you log back in.
# Create a new labeled session: screen -S k6 # (ctrl+a, d for detaching) # To list all current screen-sessions: screen -ls # To resume a running session: screen -r <id>
Be careful as you can launch screen-sessions inside other screen-sessions, which can be confusing and you might leave something running by mistake. Another alternative is to use the Docker-containers provided by k6.
Anyway, to stat your test:
k6 run --out csv=test_result.csv test.js