This post was most recently updated on July 31st, 2022.
2 min read.Is your Azure Web Application suffering from absolutely horrible load times every time someone accesses it for the first time every 15 minutes or so? Mine was. It was pitiful.
I was developing a web-based service using EF6 and ASP.NET MVC 5, where all the assets were hosted in Azure. Even though the app was reasonably lightweight and usually responded very fast, the first time someone accessed it in a while it took 20-60 seconds to load AND sometimes even timed out (especially with mobile clients). Load testing revealed only what I already knew: initial load times were horrendous, but after that everything worked fine. I did eventually find the solution, though!
Solution – Adjust the minimum connection pool size of your Azure Web Application
I tried a few things, like enabling Always On and upgrading both the DB and Web app tier in the Azure management portal (from Basic to Standard). However, these actions had little to no effect on the timeouts. However, adjusting the connection string to add a “min pool size” to DB connections and presumably make them a little more long-living helped in my case.
In your config files, in the connection string -part (shown below), look for the “Min Pool Size=3”-part:
<connectionStrings> <add name="DefaultConnection" connectionString="Data Source=....mdf;Min Pool Size=3;Initial Catalog=..." providerName="System.Data.SqlClient" /> </connectionStrings>
I’ll still have to test this a bit to find an optimal connection pool size, but already this change helped enormously.
What else can you do?
If you really, REALLY want to eliminate the latencies you get for the first load of the app service, you can prevent IIS from shutting down your process by making sure it doesn’t hit the idle timeout that’s set (internally) for the app service. In order to achieve that, just get a ping testing service to ping it every 5 minutes or so. This should prevent the process from shutting down, as I believe the default Idle Timeout is 20 minutes. You could also implement this yourself as a simple C# program running in a webjob, or even as a scheduled Flow making an HTTP request to your site.
I suspect this would be against Azure’s EULA though… At least on Shared/Free tiers, you’re kind of circumventing the missing “Always On” -switch, after all! It also kind of eliminates the whole idea behind infrastructure being used flexibly. Just something to think about.
Anyway, hope this helps!
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
