Solving Azure Web Application’s first load perfomance issues

Microsoft Azure logo

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 the 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 the 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 DB and Web app tier in 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:

    <add name="DefaultConnection" connectionString="Data Source=....mdf;Min Pool Size=3;Initial Catalog=..." providerName="System.Data.SqlClient" />

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!

The following two tabs change content below.

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.This is his personal professional (e.g. professional, but definitely personal) blog.

Let me know your thoughts!

This site uses Akismet to reduce spam. Learn how your comment data is processed.