Azure web app autoscaler is sending traffic to new node before it is ready

Question

I have my web app which using s1 plan and I have autoscaling rules

So now the problem is each time app is scaled OUT my app is basically down for good 5-10 minutes.

Long time ago i started on this problem and added
<applicationInitialization doAppInitAfterRestart="true" skipManagedModules="false">
<add initializationPage="/api/warmup" />
</applicationInitialization>

So this fixed my problem so when i do new deployment and Swap slots app is alive during that.

So facing issues with scaling i read that app service has now health status

But that did not help me too, but i noticed that since i have url rewrite to redirect http -> https, so i thought oh yes thats my problem and i fixed that few days ago, but again today my app died again and I am really disappointed since i dont have any other ideas what is wrong.

<rule name="No redirect on warmup request (request from localhost with warmup user agent)"
stopProcessing="true">
<match url="(.*)" />
<conditions logicalGrouping="MatchAny">
<add input="{REQUEST_URI}" pattern="^/api/warmup" />
<add input="{REQUEST_URI}" pattern="^/health-status" />
</conditions>
<action type="Rewrite" url="{URL}" />
</rule>

Only one thing which helps is scale up to S2 so each node starts faster but again then i will need to pay more for those resources.....

Answer 1

@Volodymyr Bilyachat , Apologies for the delay and any frustration with this issue.

To get to the root of this issue in a quick time, I wish to engage with you offline for a closer look and provide a specialized assistance, so I'm follow-up with you privately.

If you haven't done this already, kindly set the WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 app setting on all slots.
-After slot swaps, the app may experience unexpected restarts. This is because after a swap, the hostname binding configuration goes out of sync, which by itself doesn't cause restarts. However, certain underlying storage events (such as storage volume failovers) may detect these discrepancies and force all worker processes to restart. See this doc.

Thanks for the detailed description of the issue and your time.

Answer 2

To update/from our offline discussion:

VolodymyrBilyachat-6989 was able to narrow-down the problem further, it was due to huge timeout setting for SQL. Scaling-out in such cases, would be helpful.

@Volodymyr Bilyachat , thanks for the follow-up and sharing the solution that worked for you.

------------------------------------------------------------------------------------------------------------------

To benefit the community find the right answers, please do mark the post which was helpful by clicking on ‘Accept Answer’ & ‘Up-Vote’.