First look you typically take is to check the main metrics for the webservice like CPU and RAM. But CPU was always around 10%-15% and RAM was around 60% - 70%. So no big deal.
But the time to answer requests was very bad. (Left side without modification. Right side with modification).
Then I checked the database and it looked fine on the first place. When you see this you would never mind that this is still an issue! But when you look deeper into it you will find that Azure starts to show this with aggregation type "AVG"= Average values. (You will find the dropdown in the right upper corner of the graph) So what you see is just a cummulation over time. And this can be really misleading! (Left side still the bad situation before modification, right side with modification)
After changing the aggregation to the aggregation type "MAX" you will see this. And this makes really much more sense now. So in my situation very often the SQL server in Azure hits its limits. But not for a long time as my requests are from hundreds of users but not permanently. (Left side still the bad situation before modification, right side with modification)
But now the big question - how to fix this?
The cool thing in Azure is that nearly all ressources scale in the one or other way. And the scaling is incredible. In my situation I have initially operated the website with the smallest production SQL server instance in Azure with 10 DTUs. (For DTU definition checkout here).
To finally improve my website application performance the simple change was from 10 DTU to 20 DTU (in S1 Standard Tier). This cost me actually 12€ more per month and all users are happy again.
To do this simply move the slider in the "Configure" section of your Azure DB.
And thats it!
