Azure Auto-Heal + Multiple Instances for Blazor Server Applications

Question

I am investigating the following for my AppService instance which runs a Blazor Server-side application:
https://azure.github.io/AppService/2021/09/16/App-Service-Restarts.html#auto-heal

Scaling Operations is also mentioned right above it.

I am trying to figure out how this squares away with my Blazor application which also makes use of Azure SignalR Service for connections. Are the operations above compatible with it? As far as I know and understand, whenever an AppService resets/restarts, all circuits get reset on the server, and the client is faced with a Reload message, losing all session state established with the server. This is captured here in this issue:

https://github.com/dotnet/aspnetcore/issues/30344

In light of this limitation (which should be addressed to .NET8) I am looking for the best configuration possible to have availability while also preserving session state for my clients (if possible).

Thank you for any assistance you can provide.

Answer 1

Generally recycling process may have impact on various types of applications in different ways - like few applications might have its state in local memory which gets lost when process gets recycled. So, considering the impact on the application, it is our choice not to recycling process and consider recycle as only a last go-to option. For any application, deciding on – Is process recycling is the only way to recover from current degradation? What are the right set of conditions to recycle in auto-heal? might help avoiding unwanted restarts. Your application might have some performance benchmarks; you might use them as reference and try to correlate to configure the Auto-Heal conditions.

If Recycle Process is the action that you don’t want to perform under any circumstances and wants to completely avoid it, then instead of recycle process you can choose another action (supported conditions and actions vary depending on the type of the web app) that is either to Log an event or configure available custom action which could help you to troubleshoot the underlying root case of that behaviour. Once you find the root cause, then you can fix the underlying issue.

There is something called Proactive Auto-Heal (only for Windows app) which was enabled by default, you can opt out from it (make changes during non-business hours), if you don’t want some backend action trigger to recycle process. Proactive Auto-Heal is an extension to the auto healing feature of Azure App Service. It will only take corrective actions for the sites that we have deemed to be in a bad state for which the best way to recover is to simply restart them.

You can use Auto-heal as a proactive tool only to temporarily mitigate an unexpected behaviour until you find the root cause. Also, one can understand how frequently auto-heal is getting triggered, from the “Auto-Heal history”.