In module 3.9 you made the Kladde resilient: time limits for every outgoing call, retries only where they are allowed, a cache for the
free appointments and rate limiting per visitor address. In 3.8.6 you used a load generator to measure how fast the Kladde answers on
your machine. Both happened locally. This lesson measures the Kladde where it runs: in the new subscription, against the environment
test, with the target from 3.10.1. At the end there is a result that confirms the target, or an explanation with measurements of why it
does not.
The target from 3.10.1 reads: "The booking page is fast, 95th percentile of the response time under 500 ms in the load test." Before you measure, this sentence is still missing something.
What is different in Azure
On your machine the Kladde ran warm, with no network in between and a database in a container. In Azure, things come in that distort a measurement or show up only there:
| What | What happens | What it means for the load test |
|---|---|---|
| Scaling to zero | test has no running replica until the first request comes. That request waits until a container has started (3.10.1). |
The first seconds measure the cold start, not the page. They belong in a warm-up time and are looked at separately. |
| HTTP scaling | Container Apps adds a replica when more concurrent requests arrive than the rule allows (default: 10). It counts every 15 seconds: the requests of the last 15 seconds divided by 15. | A short burst does not trigger a new replica. Only a load that lasts a while shows how the Kladde scales. |
| Serverless database | The free Azure SQL database pauses when nobody uses it (3.6.1). The first connection afterward waits until it is running again, or fails. | This belongs in the warm-up time too. A run that begins with errors after a pause is no result about the page. |
| Rate limiting | The booking form allows five requests per minute and address (3.9.4). A load generator is a single address. | Load on the form measures the limit. What you measure is the page a visitor opens first, with GET. |
| Network | Between the generator and the Kladde lie the internet and the Container Apps ingress. | The time at the client is greater than the one the server measures. You read both, and the difference tells you something. |
| Size of the environment | test runs the same version as prod, but perhaps in different sizes (3.2.6). |
A result holds for the size it was measured against. That goes in the log. |
The fourth point is the most important, and it is a field report from the practice of many teams: a load test against a form with rate limiting reports nothing but fast answers after a few seconds, namely 429. Anyone who looks only at the response time is delighted with a fast application. Don't switch the rate limiting off for a load test either: then you are measuring a Kladde that doesn't run that way in operation. Choose instead what you measure, and have the generator report 429 as a number of its own.