Design considerations
Supported applications
This solution supports cloud-based applications, and on-premises applications as long as you have a network connection from your AWS account to your application. The solution supports APIs that use either HTTP or HTTPS. You also have control over the HTTP request headers, so you can add authorization or custom headers to pass tokens or API keys.
JMeter script support
When creating a test scenario using this solution’s user interface (UI), you can use a JMeter test script. After selecting the JMeter script file, it is uploaded to the <stack-name>-scenariosbucket Amazon Simple Storage Service (Amazon S3) bucket. When Amazon Elastic Container Service (Amazon ECS) tasks are running, the JMeter script downloads from the <stack-name>-scenariosbucket Amazon S3 bucket and the test runs.
If you have JMeter input files, you can zip the input files together with the JMeter script. You can choose the zip file when you create a test scenario.
If you would like to include plugins, any .jar files that are included in a /plugins subdirectory in the bundled zip file will be copied to the JMeter extensions directory and be available for load testing.
Note
If you include JMeter input files with your JMeter script file, you must include the relative path of the input files in your JMeter script file. In addition, the input files must be at the relative path. For example, when your JMeter input files and script file are in the /home/user directory and you refer to the input files in the JMeter script file, the path of input files must be ./INPUT_FILES. If you use /home/user/INPUT_FILES instead, the test will fail because it will not be able to find the input files.
If you include JMeter plugins, the .jar files must be bundled in a subdirectory named /plugins within the root of the zip file. Relative to the root of the zip file, the path to the jar files must be ./plugins/BUNDLED_PLUGIN.jar.
For more information about how to use JMeter scripts, refer to JMeter User’s Manual
K6 script support
The solution supports K6 framework-based testing. K6 is released with AGPL-3.0 license
Locust script support
The solution supports Locust framework-based testing. The Locust test file along with any necessary input files can be included in an archive file and uploaded for the test scenario using the upload option.
Scheduling tests
You can schedule tests to run at a future date or use the Run Now option. You can schedule a test as a one-time run in the future or set up a recurring test in which you specify a first run date, and planned recurrence. The options for recurrence include: daily, weekly, bi-weekly, and monthly. For more information on how scheduling works, refer to the Test scheduling workflow section of this guide.
Starting in version 3.3.0, Distributed Load Testing on AWS allows users to schedule load tests using cron expressions. Select Run on Schedule and then the CRON tab to either manually enter a cron value or use the drop-down fields. The cronExpiryDate must match the scheduled test run date. Review the Next Run Dates (UTC) to confirm your schedule.
Note
-
Test duration: Consider the total duration of tests when scheduling. For example, a test with a 10-minute ramp-up time and 40-minute hold time will take approximately 80 minutes to complete.
-
Minimum interval: Ensure the interval between scheduled tests is longer than the estimated test duration. For example, if the test takes about 80 minutes, schedule it to run no more frequently than every 3 hours.
-
Hourly limitation: The system does not allow tests to be scheduled with only a one-hour difference even if the estimated test duration is less than an hour.
Concurrent tests
This solution includes an Amazon CloudWatch dashboard for each test and displays the combined output of all tasks running for that test in the Amazon ECS cluster in real-time. The CloudWatch dashboard displays the average response time, the number of concurrent users, the number of successful requests, and the number of failed requests. Each metric is aggregated by the second, and the dashboard is updated every minute.
User management
During initial configuration, you provide a username and email address that Amazon Cognito uses to grant you access to the solution’s web console. The console does not provide user administration. To add additional users, you must use the Amazon Cognito console. For more information, refer to Managing Users in User Pools in the Amazon Cognito Developer Guide.
For migrating existing users to Amazon Cognito user pools, refer to the AWS blog Approaches for migrating users to Amazon Cognito user pools
Regional deployment
This solution uses Amazon Cognito which is available in specific AWS Regions only. Therefore, you must deploy this solution in a region where Amazon Cognito is available. For the most current service availability by Region, refer to the AWS Regional Services List