Locust is an open-source load testing tool written in Python. It allows you to write tests for your web application which mimic your user’s behavior, and then run the tests at scale to help find bottlenecks or other performance issues. In this workshop, you will use Locust to load test the inventory service. Locust has been deployed to your account and is accessible from your Visual Studio instance at http://locust.unishop.local.
When you visit the Locust website for the first time, the site will ask you to start a new Locust run. If not, please click the “New test” link in the top right corner of the page. Then, you can specify some arguments for the test.
To start a Locust test, you should specify the number of total users to simulate, the number of spawned users per second, and the host to test.
Follow instructions below to set the arguments. Then click “Start swarming.”
“Host”: Enter the value of “API Gateway Invoke URL” in your cheat sheet
“Number of total users to simulate”: Enter 300
“Hatch rate”: Enter 10
Make sure there is no slash at the end of the “Host” value. Otherwise, the test will fail.
After you start the test, you can see the statistics of the last load testing. Each row records the statistics of a specific kind of API request.
It will take about 5 to 10 minutes to trigger the auto-scaling. Please be patient if you don’t see the auto-scaling result.
1.1 In the AWS Management Console, navigate to CloudWatch.
1.2 In the CloudWatch Console, you will notice a tab named “Alarms” on the left side. Click that tab, then you will see all the alarms show up.
1.3 In the list of alarms, you will find an alarm with name like “TargetTracking-service/UnishopCluster/InventoryService-AlarmHigh-RANDOM_UUID.” Click the name of that alarm.
There are two alarms for the InventoryService. One is named as “TargetTracking-service/UnishopCluster/InventoryService-AlarmHigh-RANDOM_UUID,” while the other is named as “TargetTracking-service/UnishopCluster/InventoryService-AlarmLow-RANDOM_UUID.” You should click the former one instead of the latter one.
1.4 Then you will see the detailed page of the alarm. Here, you can check the state of this alarm. (The state is in the top right corner of the “Graph” section.) If it is still “OK,” then you have to wait another serveral minutes until it becomes “In alarm”. To see the latest state and diagram, you can click the refresh button.
1.5 When the state becomes “In alarm,” it means the inventory service has been scaled out. Now let’s check the service in ECS.
Check the number of running tasks.
2.1 In the AWS Management Console, navigate to Elastic Container Service.
2.2 In the Elastic Container Service Console, you can see the number of running tasks is more than 1, which means the inventory service has been scaled out. If you don’t see this change, you may need to wait a little longer.
Before you go to next lab, remember to STOP the locust test! Please go to the Locust panel and click the “Stop” button in the top right corner.
Congratulations! You have successfully strangled out the last service from the monolith application. However, the inventory data is still stored in the original monolith database. In the next lab, we will migrate the data into an Amazon Aurora database. Let’s go!