1

I’m currently dealing with very annoying performance problems after deploying an ASP.NET MVC4 application to Microsoft Azure. Right after restarting the app (or after a few minutes of inactivity) some pages take about 15 seconds to load for the first time. After this, even when clearing the clientside cache those pages will load in about 2 seconds (which is still in need of improvement but way better than 15 seconds, which is a huge user experience killer).

Here’s what I’ve already tried so far:

  • I combed through every event in Global.asax in order to replace database-related code with dummy-code
  • Changing the publish settings to: «Precompile during publishing» (Merge all outputs to a single assembly)
  • According to Azure’s «App Performance Analysis» my app is considered «healthy»
  • «Always On» is activated within the portal's app settings (The pricing tier is B1 [Basic, 1 Core, 1.75GB RAM], therefore I assume that the always-on-switch doesn't get overridden by the shared runtime configuration)

Since none of the bullets above solved my issue I tried out to write a keppalive-Job using Quartz.NET that regularly requests the website like this:

new System.Net.WebClient().OpenRead("https://foo.azurewebsites.net");

(In my case, I think the effect is more or less the same as declaring initializationPages within Web.Config as mentioned here, isn’t it?)

The result: It works, but just for this specific URL. Maintaining a list of every possible route definitely isn't the way to go.

Have you ever dealt with this issue? I’d highly appreciate your inputs!

Alan
  • 411
  • 6
  • 18

2 Answers2

3

It has been some time since I was working in an organization that hosted on azure but they used to have an option that you could configure labeled "Always On" which would in effect be the equivalent of setting the idle timeout to zero on a application pool and keep your application loaded into memory. Otheriwise without traffic then your site will be unloaded and forced to JIT upon first hit (kinda like after initial deploy).

I've read about others creating mock http request to their sites to keep the traffic up going and avoid the unload from memory when they were subscribed to the lower priced tiers that did not offer the "always on" option.

Edit: Here is another SO post addressing it: App pool timeout for azure web sites

Travis Acton
  • 4,292
  • 2
  • 18
  • 30
  • Thanks for your input. I forgot to mention: The pricing tier of the app is B1 (neither a free nor a shared plan). Therefore, I think that in this case the "Always on" option should do what it's supposed to. Isn't it? I'll update the question. Mocking HTTP requests is exactly what I try to avoid, since this would mean to maintain a list of URL's. – Alan Dec 20 '17 at 17:18
  • @Alan...this is the answer. I use it for exactly your situation – Big Daddy Dec 20 '17 at 17:47
  • Seems like we can't come around mocking HTTP-requests for each page in order to force the JIT-compiler to warm it up, can we? :) I'll post a new answer to explain in detail the solution I finally contented myself with. However, I'll mark this answer as the accepted one, since it lead me in the right direction. Thanks to both, Travis & Big Daddy! +1 – Alan Dec 21 '17 at 12:20
1

In addition to the accepted answer I wanted to explain in detail how I finally dealt with this issue. Maybe this may help someone else in future. I wrote some code to warmup the application on startup by simply triggering a web-request on critical sites (I've made the experience that this needs to be done for every single page. Just warming up the root address won’t suffice). 

private void WarmUp()
{
  var baseUrl = "https://foo.azurewebsites.net";

  /**
   * Requests to protected pages need to be authenticated and authorized, otherwise the JIT-Compile won't work
   * For ASP.NET apps that are using FormsAuthentication just send a POST-request as you normally would do using a html form,
   * then grab the cookie you get in the response and pass it to the subsequent requests
   * */
  var email = "warmup.worker@foo.com";
  var password = "verysecure";
  var cookies = new CookieContainer();

  var webRequest = WebRequest.Create($"{baseUrl}/Account/Login") as HttpWebRequest;
  webRequest.Method = "POST";
  webRequest.ContentType = "application/x-www-form-urlencoded";
  webRequest.CookieContainer = cookies;

  var requestWriter = new StreamWriter(webRequest.GetRequestStream());
  requestWriter.Write($"user={email}&password={password}");//Small example for brevity. Don't forget to extract the requestVerificationToken in production :-)
  requestWriter.Close();
  webRequest.GetResponse().Close();

  var urls = new[] {
    baseUrl,
    $"{baseUrl}/Home/Contact",
    $"{baseUrl}/Protected/Stuff",
    //...
  };
  foreach (var url in urls)//trigger web-requests
  {
    webRequest = WebRequest.Create(url) as HttpWebRequest;
    webRequest.CookieContainer = cookies;
    webRequest.GetResponse().Close();
  }
}

This triggers the time-consuming JIT-stuff for us when the app starts/after deployment, thus preventing our users to experience horrible performance when requesting the page. If your app’s pricing plan is S1 or higher you can improve performance even more using deployment slots. They allow you to warmup the app even before deploying to production.

In my case (reserved pricing tier, B1), I think it is enough to run the code above once within Application_Start, since «Always on» should prevent my app’s worker process from being shut down automatically in case the site doesn’t get any traffic for a set period of time (If your app is running on shared resources make sure to keep alive your app using a Cron job or something similar).

Alan
  • 411
  • 6
  • 18