- What IP addresses are used by the k6 Cloud?
- What is the best way to debug my load test scripts?
- I was invited to an organization and I cannot run tests
- What's the difference between LoadImpact's version 3.0 (Lua) and k6 Cloud?
- How to open a firewall to k6 Cloud service for cloud tests?
- Test status codes
- What are VUs (Virtual Users)?
- How many VUs can be run from the same Dedicated IP?
- Data uploads with k6 Cloud
- Pricing FAQ
k6 uses AWS for cloud load generators. For the IP addresses used in the different load zones and filtering methods please refer directly to Amazon.
If you prefer to view the ranges directly, within the above link, the ip-ranges.json file provides the updated list of IP addresses used by our load generators. In order to know which IP ranges can be used, you need to filter the service of type EC2 and the region of the selected load zone/s in your test configuration.
The zone codes are mapped as follows:
- us-east1: Ashburn
- us-east-2: Columbus
- us-west-1: Palo Alto
- us-west-2: Portland
- ca-central-1: Montreal
- eu-west-1: Dublin
- eu-central-1: Frankfurt
- eu-west-2: London
- ap-northeast-1: Tokyo
- ap-northeast-2: Seoul
- ap-southeast-1: Singapore
- ap-southeast-2: Sydney
- ap-south-1: Mumbai
- sa-east-1: São Paulo
Debugging helps to ensure your code produces the expected results. While there is a script editor built into the k6 web application, it has limited debugging abilities.
Using k6 locally, you can actually execute your test scripts on a small scale to quickly see how the script executes. Debugging locally is beneficial for two reasons:
- A cloud test counts against any subscription limits you may have.
- Execution is slower when streaming or executing in the cloud. We want debugging to be a fast iterative process.
If you've configured Virtual Users or duration in your script, adding the flags -i 1 -u 1 instructs k6 to execute 1 iteration with 1 Virtual User, making the debugging sometimes easier.
To develop and debug your load tests, we recommend, in most cases, running your tests locally - using the k6 run command.
When your script is ready, execute the test on the k6 Cloud with the k6 cloud command.
For debugging, k6 also provides a few builtin options:
- console logging methods
Also, logging methods can print any message to the console. In the cloud, the console logs are shown on the Logs Tab.
I was invited to an organization with a subscription. However, When I try to run tests, I get an error that my subscription doesn't have enough Virtual Users/exceeds the duration/uses too many load zones. Our subscription allows for the test I want to run. What is wrong and how do I fix this?
If you encounter a similar situation, probably, the problem is that you run the test from a different organization with another subscription.
This situation often happens because when you register your account, the k6 Cloud automatically creates a "personal" default organization for you. In this case, you might have two organizations; your "personal" organization and the invited organization.
By default, tests run from your "personal" organization.
How do I change the organization to fix this?
If you run tests from the web interface, you will need to use the User menu - on the top of the left sidebar- to select a project within the desired organization.
If you run tests from the k6 CLI, you will need to set the projectID in the test script.
To do this, copy the project ID from the top left corner of the project dashboard (see image above) and set the projectID as a cloud execution option.
Read more here.
If you are running a k6 cloud test, you will be utilizing k6's cloud infrastructure. These are dynamically allocated from our cloud providers and we do not know the source IP until the test is running.
To open your firewall to k6 cloud traffic, you have multiple options.
1 - Open up your firewall to the whole range of AWS IP addresses used by the load zones where you want to run your load test from. We list here the full range of IP addresses.
2 - Use HTTP headers, URL query parameters, or unique data that identifies the traffic as belonging to your load test, This requires that your firewall has support for scanning application payload data and apply rules based on what it finds. Here is some examples:
2.1 - You can add custom HTTP headers to any request in your script. You'll need to add the header to every single request.
2.2 - If you're not dependent on having the simulated users in your load test to be a certain user agent, you can also use the userAgent option to set the "User-Agent" header for all subsequent requests. That header could then contain your token value and you would not have to modify every single HTTP request in your script. In the below example the user agent is set to MyK6UserAgentString/1.0
2.3 - You might also use query parameters, if it doesn't interfere with the functionality of your application:
3 - Another option would be to request content from a certain hostname that is not in the DNS, but your site would of course need to be configured to respond to requests for that hostname. This is how you do it on the k6 cloud's side:
This last solution requires that your firewall terminates SSL traffic, otherwise it will not see the Host header in unencrypted form. You could also use unencrypted HTTP, but get a bit less security.
Below the list of test statuses in k6 along with the code returned. The code returned here is different than what is returned by k6.
Every successful test, will go through the following statuses. The time from Created -> Running, is typically very short and hardly noticeable as you use the platform.
A test that is newly created, but has not yet been validated.
A test which has finished initial validation, but has not been queued to run yet.
A test which has entered our queue. Once it is picked up by a test worker, it will begin initializing.
A test which has been assigned to Load Generators, but has not yet started to make HTTP requests.
A test which is actively making HTTP(s) or websocket requests
A test which has finished running. If thresholds were used, no thresholds have failed.
A test which has not received or sent any information for a long time
A test which was aborted by the user. Tests aborted by user count against your total usage.
A test that was aborted by the system. These tests typically abort due to a fatal error occurring. If the test fails before launch, there may be an underlying issue with the Load Zone, unrelated to k6. If the test aborts during execution, it may be due to overutilization of the Load Generators. In this case, we suggest you look at the CPU and Memory utilization and add or increase sleep times. You may also want to set the option discardResponseBodies to true, to lower memory pressure.
A test that was aborted due to an error in your script. For example, if you were to capture data from the response body of a request that you reuse in a future request. If the first request were to fail, your future request would contain a null value. Sudden script errors can suggest a performance issue. Fix the performance issue or add error handling to account for these cases.
A test that exceeded your defined threshold value and that threshold was given the option to automatically abort the test.
A test that has exceeded one or more of the following limits:
- The test contains too many groups (>40)
- The test reports too many metrics (>10,000)
- The duration is longer than 60 minutes (for tests longer than 60 minutes, please contact us)
- The max VUs is higher than 20,000 VUs (for tests higher than 20k, please contact us)
If your test has too many groups, please reduce their number. If your test has too many metrics, please use URL grouping to combine similar URLs. You should also remove external requests from your test script. Each URL captured will account for 7 individual metrics that we keep track of. External requests can quickly produce a large number of metrics that aren't helpful to the understanding performance of the System Under Test.
Virtual Users (VUs) mimics the behavior of a real user. They are used to perform separate and concurrent executions of your test script, making HTTP(s) and WebSocket requests against a webpage or API. Read more here.
We run a maximum of 300 VUs from a Dedicated IP. If you want to run a 1000 VU test from Dedicated IPs you'll need at least 4 IPs. If you want to run a 5000 VU test from Dedicated IPs you need at least 17 IPs.