AppService: Always On Does Not Appear to Be Always On

Mike-E-angelo 476

I am experiencing an issue with an AppService where after some time of not using it, and then attempting to use it, it will take nearly 15 seconds to respond. After this the application is very responsive as expected. I have Always On set in the configuration, so I am a little confused on what is happening here, as it seems that the AppService is not Always On despite having this property enabled.

Thank you for any assistance /insight/suggestions you can provide.

VenkateshDodda-MSFT 18,436 Reputation points Microsoft Employee

2022-09-26T08:54:20.843+00:00

@Mike-E-angelo Thank you for reaching out to Microsoft Q&A. Apologize for the inconvenience caused on this. Apologize for the inconvenience caused on this. Based on the shared information i have understood that your web app is taking longer time to respond even the Always on is enabled. I would suggest you run the Diagnose and solve problems to identify the performance issues in your web app.

In general, Websites unload if they sit idle for too long, which helps the system conserve resources. This Always On setting keeps your site up and running, which translates to higher availability and faster response times across the board.

so I am a little confused on what is happening here, as it seems that the AppService is not Always On despite having this property enabled.

Could please help us sharing more information how you are validating this behavior.

You can check whether Always On is enabled or not through kudu console under environment settings as shown below or through the AlwayOn Check (DAAS) under Diagnose and solve problems.
Mike-E-angelo 476 Reputation points

2022-09-26T09:42:13.343+00:00

Thank you for your reply @VenkateshDodda-MSFT it is appreciated.

I would suggest you run the Diagnose and solve problems to identify the performance issues in your web app.

Thank you for that suggestion. Unfortunately, I find this interface incredibly confusing, overwhelming, and most unhelpful. It is also incredibly slow which is a total embarrassment for Microsoft as this "portal" is meant to be a bastion example of cloud architecture. The next time this "feature" actually assists in determining an issue for me will be the first.

(I complain about this here as this is always suggested as a recommendation but never actually really helps)

Nonetheless, I poked around and all I see is green? EVERYTHING IS FINE NO PROBLEMS HERE :) (see above)

Additionally, I can confirm Always On is enabled using your guidance:

(This Kudu site took over 15 seconds to load btw... so slow!)
Mike-E-angelo 476 Reputation points

2022-09-26T09:42:25.49+00:00

I have a feeling I am going to have to open yet another Azure "Support" ticket where the "support engineer" will spend two weeks wrangling with my copy/pasting the same above type guidance and I will have to spend those two weeks replying and retorting to say that I have already gone through said guidance before they will actually make the effort to forward this to an "internal team" to see what is actually going on with my application. All for the low price of $1,200/year.

(No, my impression of Azure "support" at the moment is not exactly sterling :))
VenkateshDodda-MSFT 18,436 Reputation points Microsoft Employee

2022-09-26T11:24:33.737+00:00

@Mike-E-angelo Apologize for any inconvenience/ frustration caused on this. I would reach out to you over private message for webapp and subscriptions details to investigate(to review the backend logs) and to assist you further.

Just to clarify, Diagnose and solve problems is equipped with multiple DAAS services(Diagnostics as a Service) it provides insights and pointers as a first step to isolate the web app issue from your end. whenever you open the Diagnose and solve problems page of your webapp you will be navigated to the below shown page

Based on the type of issue you select the particular DAAS service suppose in your case you are webapp is taking longer time to respond then you can choose the Web App Slow service and this will intern run some quires in the back end and will share the possible observations and solutions as shown below.

As mentioned in my earlier response you can use search bar in Diagnose and solve problems Always on Check and validate whether Always on is enabled or not.

You can refer to this performance issue on azure web app documentation https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-performance-degradation and try to isolate the webapp issue and let us know if you still face the issue.
Mike-E-angelo 476 Reputation points

2022-09-26T11:55:57.953+00:00

Thank you for your continued assistance @VenkateshDodda-MSFT . It appears the Always On ping is resulting in 302:

However, it is unclear to me why this is causing the application to shut down because that 302 is redirecting to a sign-in page, which is still in my application. It would seem my application is still "active" because it is loading the sign-in page.

Based on the type of issue you select the particular DAAS service suppose in your case you are webapp is taking longer time to respond

Please note that the application is "slow" because it has shut down. It is only taking 15 seconds to load on the first attempt after being idle. After that, it is very responsive as expected. :)
VenkateshDodda-MSFT 18,436 Reputation points Microsoft Employee

2022-09-28T12:23:56.2+00:00
@Mike-E-angelo Thanks for your follow-up questions. I have looked at the back-end logs below are the couple of observations:

Since AlwaysOn is returning non 200 responses, the app is being shut down after 20 mins of inactivity. This is by design and since the redirect is happening in the code itself, I would request you to add an exception for the user agent "ALWAYSON" so that the app doesn't suffer from long preload times that we observed in our backend logs (>25s).

We also recommend to use App Initialization to ensure that the specific pages are warmed up before serving actual customer requests.

Feel free to reach back to me if you have further questions on this.
Mike-E-angelo 476 Reputation points

2022-09-28T12:33:02.567+00:00

Thank you for your time and investigation @VenkateshDodda-MSFT . So if I can figure out a way to get 200 responses then this will address the problem? Note that I am already using application initialization and WEBSITE_SWAP_WARMUP_PING_PATH is set to the login page, which should return 200s, so I am confused on where Always On is pinging and/or where that is configured.
Mike-E-angelo 476 Reputation points

2022-09-30T15:03:25.29+00:00

Hi @VenkateshDodda-MSFT are you able to confirm how to configure Always On to use a different URL? I did a search but nothing returned was obvious. Thank you for any assistance you can provide.
VenkateshDodda-MSFT 18,436 Reputation points Microsoft Employee

2022-10-03T08:59:34.98+00:00

@Mike-E-angelo Apologize for the delay in my response. I have checked with my team on routing the AlwaysOn to different URL instead of hitting to root (/) unfortunately didnt found any insights on that. I would suggest you raise a support ticket to App service team. They help you further in addressing your questions and in-depth troubleshooting as well.
Mike-E-angelo 476 Reputation points

2022-10-03T09:31:50.2+00:00
No worries @VenkateshDodda-MSFT I appreciate you checking back in. There are a lot of MSFT personnel on here that ghost after a certain amount of time/posts and even though I understand it's free support, it doesn't look good no matter the reason, especially when it occurs more than once (I have about 5 of them up to this point it seems).

Anyways, I was able to get the following to "work" by adding this to my @page "/" route of my Blazor application:

@functions { public IActionResult OnGet() { if (Request.Headers.UserAgent.ToString().ToLower().Contains("alwayson")) { return new OkResult(); } return Page(); } }

I put "work" in quotes because now it takes 6 seconds to warm up my "Always On" application rather that 16. :P So, progress? :P
VenkateshDodda-MSFT 18,436 Reputation points Microsoft Employee

2022-10-03T11:24:39.49+00:00

@Mike-E-angelo Thanks for the follow-up. Glad to know that you were able to improve the load time by 10sec, that's a fine progress.

Just to confirm on this thread, it's only me responding to you, privately and publicly, are you referring to any other Q&A thread or replies from our engineers on the same thread.
Mike-E-angelo 476 Reputation points

2022-10-03T12:57:03.98+00:00

Hi @VenkateshDodda-MSFT no not this thread but you are welcome to go through my history and find the ones I am referring to :D In particular, is this thread which I am not calling out because of the engineer, but because it is now relevant to this thread:

https://learn.microsoft.com/en-us/answers/questions/807835/swap-warmup-takes-same-time-as-straight-deployment.html

Basically now it takes 6 seconds to load my application and this also occurs during "warmup" swapped deployments. After these long delays occur on the first request, everything is very responsive as expected. I would not expect these delays for an application that is "Always On" and has been warmed up via swap. There also appears to be a delay that is introduced after not using the application for a while. Again, this is not expected for "Always On." I hope this helps explain my concern.
Mike-E-angelo 476 Reputation points

2022-10-04T08:22:31.743+00:00

Hi @VenkateshDodda-MSFT thank you for your continued assistance. FWIW I did a refresh on my application this morning and it took 10 seconds to load. So now with the AlwaysOn user agent "fix" in there the application takes 6-10 seconds to load up for an "always on" application. This still seems very broken to me.
VenkateshDodda-MSFT 18,436 Reputation points Microsoft Employee

2022-10-04T11:21:18.007+00:00

@Mike-E-angelo This would need one on one offline support, for deeper investigations and might need to engage product team as well and I will suggest you to open a support ticket.

1 answer

Mike-E-angelo 476 Reputation points

2022-10-08T20:51:22.33+00:00

Woohoo! SMALL VICTORIES! It looks like I did not have the user agent fix properly deployed. I thought for sure I did, but apparently I did not. I did a full system deployment earlier today, and I have been able to refresh my AppService after a couple hours of no use, and it loads SO MUCH BETTER NOW.

Additionally, I upgraded the instances to P2 and it is BLAZING FAST. I got accepted into Microsoft for Startups Grow stage and am now taking advantage of those credits. :)

Anyways, thank you for all the help. Things are much better now
Please sign in to rate this answer.
Tom Puleo 6 Reputation points

2023-03-03T14:03:34.75+00:00

What is the "user agent fix"? I'm having the same issue. Always On is ON, but app still goes to sleep. My guess is that I set a default page that's just .html. Maybe I need to set the default (somehow) to a page that actually does something. I'm using .NET 7.

Mike-E-angelo 476 Reputation points

2023-03-06T10:42:29.2233333+00:00

Thanks for the inquiry @Tom Puleo I actually have this encapsulated in open-source code if you want to take a peek and copy/paste it for your own purposes. It's MIT License so knock yourself out. :)

Starting with an extension method for your IApplicationBuilder here:

https://github.com/DragonSpark/Framework/blob/master/DragonSpark.Server/Requests/Warmup/Extensions.cs

You can also skip the code and go to the article I used as reference here (linking a comment in the article with important information): https://haacked.com/archive/2020/09/28/azure-swap-with-warmup-aspnetcore/#6b495a64

Tom Puleo 6 Reputation points

2023-03-06T13:43:24.8766667+00:00

Thanks @Mike-E-angelo , I didn't realize it was a redirect issue, so I ended up making an Azure function that calls a particular controller action in my app that actually does a little work and returns some text. It runs every 15 minutes, and seems to have worked. I'll try out the simpler solution. :) Thanks, again.
Sign in to comment