Time Required: 10-15 minutes
The included script provides a sample load test against your demo environment to see how it responds and at what point it fails.
NOTE: The only section you must complete is the configuration. You can then excute the tests. All other sections are for information purposes only should you wish to experiment with the script options.
There is a single step to configure the script.
- Open the script and, on line 5, replace
{trafficManagerUri}with the value of the variable from deploying your infrastructure. This will be the public URL (FQDN) of your traffic manager.
There are two ways to execute the k6 script.
If you are running Docker, k6 is available as a container. It is possible to execute the tests in the script by injecting it into the container runtime.
Provided that you have Docker installed (and running) locally and the script is downloaded to your current folder:
docker run -i loadimpact/k6 run -<script.jsIf you find yourself writing k6 scripts often, you may prefer to install k6 locally. By installing it on your machine, you can take advantage of additional benefits like colorized reporting and multiple files for test suites, which can be extremely beneficial compared to a single file for all tests.
After installing k6, run it locally with the following:
k6 run script.jsk6 offers four different types of custom metrics. In this demo script, we are only focused on two - Trends and Rates. The trends and rates that we have configured will allow us to track various custom metrics across our tests. In our case, for each suite of tests, we are tracking the requests duration and the number of errors encountered.
For each test suite, we capture the duration by getting the current date/time before the request and subtracting it from the date/time after the test as completed. By adding it to the trend, we can monitor the duration of requests as the load increases/decreases.
Additionally, we capture the rate of errors that each test suite generates. Every time we encounter an error in the request, we add 1 to the rate counter. A percentage is then generated by the dividing the total number of errors by the errors for this specific test suite. The logic could be a little more robust, however, keep in mind that our goal with this script is to keep it simple and accelerate your ramp-up time.
There are many different options for customizing your k6 tests run. However, for this demo, we are only concerned with two - stages and thresholds.
Stages allow us to mimic a stair-stepped approach to introducing load on our system. For stages, there are a minimum of two different values you will need to configure for each - the duration of the stage and the number of virtual users (VUs). Keep in mind that the target is NOT the number of total requests, but the number of total virtual users. Therefore, if you are running multiple tests, and each test contains multiple HTTP requests, the each user will be performing all of those requests randomly throughout your load test.
Thresholds allow you to set your performance SLAs as determined by the business. In the case of this demo, the business has determined that no single request should take longer than 10 seconds, and while the system is under 90% of our target load, requests should not exceed 2 seconds. Furthermore, while the system is under 95% of our target load, requests should not exceed 5 seconds, understanding that as load increases, the HTTP request duration may also increase. Obviously, these are very generous thresholds, but you can adjust them to your business requirements. Just remember that the values specified here are in milliseconds. Lastly, we have specified that we are only allowing for 10% of our total requests to fail.
One thing worth noting, if none of our tests encounter failed requests, k6 will not tell us. The only time k6 will report the failure rate is when a test actually fails.
The last section (export default function() {...}) of our demo script is the main entry point for k6 execution. k6 calls this function to execute our tests, and it is from this function that we call our individual test suites.
One thing to note is that, in order to mimic the mouse clicks of an actual user, we sleep() 1 second before each test. Again, this mimics the navigation of a user on our site and reduces the potential false positive of a DDoS attack against our system under test.
Previous
Next