So far your tests have asked whether the Kladde does the right thing. A load test asks whether it still does it fast enough when many people come at once: twenty visitors who look at the free appointments in the same minute because the office sent out a newsletter. In this lesson you measure that first locally with a small tool of your own and then in Azure with Azure Load Testing. The next module, Resilience and performance, builds on these measurements.
The goal first, then the test
A load test without a goal delivers numbers, but no answer. "The page takes 180 milliseconds" is neither good nor bad as long as nobody has said what good is. So write the goal down beforehand, in a form you can measure:
With 20 concurrent visitors, the page with the free appointments answers in under 500 milliseconds in 95 of 100 cases, and at most one in a hundred requests fails.
That contains four parts: what is measured (a page or an endpoint), under what load (20 concurrent visitors), which limit (500 milliseconds) for which share (95 percent), and how many errors are allowed. Where the numbers come from is for the office to decide, not for the technology: How many visitors come at most at the same time, and at what point does a page feel slow to them?