Task 01 - Implement load testing (15 minutes)
Introduction
When some people think of load testing, the first thought that comes to mind is pointing a tool at your site, cranking the load to the max, and seeing what happens. While that might be exciting at the moment, it’s critical to take a step back and develop a load testing strategy that is tailored to the application. This means breaking down the architecture, internal and external dependencies, high availability design, scaling, and the data tier. Having a plan not only helps you prepare while you are testing the application, but it also provides context as to why and how you are testing the application for anyone in the future.
Description
The development team at Munson’s Pickles and Preserves would like to understand how to perform proper load testing on a website, using the Team Messaging System as an example.
In this task, you will create a load testing strategy to describe your plan and goals. Below are some examples of topics, but you should also think about whether there are other questions or criteria to consider.
- Define the scope of your testing, including which services you will test.
- Identify the load characteristics for this scenario.
- Identify the test failure criteria.
- Identify how you will monitor your application while performing load testing.
- Identify potential bottlenecks or limitations in advance.
- Identify any assumptions or risks in your plan.
Although the Team Messaging System itself does not experience heavy utilization throughout the day, the development team has asked you to consider a similar application with the following usage profile:
- The majority of utilization happens during business hours, which are 8 AM until 5 PM Central time in the United States.
- During normal business hours, the average daily load is 1000 users per hour and users interact with all system endpoints, not just a subset. For a load test, they would like to ensure that 30 concurrent users are able to access the site and ensure that the overall workload should take no more than 600ms per call on average. Also, no more than 10% of calls should fail under this workload.
- There are no external APIs or automated systems which add an appreciable amount of workload to the application.
Your task is as follows:
- Create a load testing strategy based on the Team Messaging System application. In addition to the Learning Resources below, you may also wish to use GitHub Copilot to assist you in coming up with ideas.
Success Criteria
- Present your comprehensive load testing plan, paying special attention to how the load test will interact with any applications or services.
- Explain what potential bottlenecks you might encounter during the test, as well as your expected mitigation strategy for each bottleneck.
- Explain how a service failure or degradation might impact the performance of the application or the load test.
Learning Resources
- How to write a test plan for load testing
- Load Testing Preparation Checklist
- An End-to-End Guide of Load Testing
Solution
Expand this section to view the solution
Below is a sample load testing plan. You should have a plan with a similar overall feel, although some specific details may vary.
- Define what services and the scope of your testing
- We will be simulating an average day when a user hits our website during normal business hours 8 AM - 5 PM. We will be testing all endpoints to ensure all features are tested.
- Environment Requirements
- Because we are testing user workloads, we will need the following resources at the same level as production.
- App Service
- Because we are testing user workloads, we will need the following resources at the same level as production.
- Identify the load characteristics and scenario
- Our current average daily load is 1000 users/hour. We will mimic the average daily load by spinning up 30 concurrent threads, hitting all endpoints. Because there is a consistent daily load, we will mimic this with gradual load increasing linearly.
- Identify the test failure criteria
- Our test will fail if we are unable to support 30 concurrent users, as we already know this is the current demand.
- We will also consider this a failed test if we find performance below the expected threshold of 600ms per call on average or if more than 10% of calls fail, as this may impact customer satisfaction.
- Identify how you will be monitoring your application
- We will be monitoring our applications with Application Insights to detect any errors and monitor performance.
- Identify potential bottlenecks or limitations in advance
- Although we do not cache data, the fact that the application is using an in-memory database should mitigate any data transfer bottlenecks.
- Identify any assumptions or risks in your plan
- We are assuming these are only casual end users and not other 3rd parties who could be trying to obtain information about our traffic.
- We are using consumption-based model for Azure App Services.
- The application does not make any database calls.
It is important to take advantage of whatever information the customer has regarding existing metrics and usage patterns, as this allows us to set a baseline for what we need to cover. This information may be incomplete, so we may need to engage with the customer to determine the state of their current system.