I have the following App Services, each with their own custom domain: domain.com content.domain.com commerce.domain.com events.domain.com support.domain.com Each of these are on their own Azure App Service and everything works well. The problem I am encountering is during deployments and I am having to use the swap slot feature. Each swap takes 90 seconds, and I have two swaps that occur during a particular deployment that is taking a lot of time: 1 to take offline 1 to restore with new content This is taking over 20 minutes as I also have worker processes that also need deployment/swapping. In light of this, the idea that I have been thinking of is putting all the App Services listed above on one App Service and make use of Virtual Applications instead. That way, I would only have 1 swap in place of 5. I have tried doing so, but it does not appear that Virtual Applications allow you to bind to custom domains. In using IIS back in the day, I would usually create a virtual application and bind a domain name to it, but that does not seem possible with App Service. Or at least, not that I can find, so I am posting here to see if there's something obvious I am overlooking. Is this possible? Can I have my domains above on one App Service and map to their respective Virtual Applications? If so, how? Thank you for any assistance you can provide.

Apologies for the delayed response @Mike-E-angelo . As you've discovered, virtual applications can't be bound to a custom domain. Reason being is because the domain is bound to the worker instance that your app service is running on. Over 90 seconds taken for the swap is definitely something to look into. The operation is pretty straightforward ; apply applicable settings warm-up the slot with HTTP requests switch routing after 200 Some things that could impact startup is the usage local cache or a lengthy application startup. The use of local cache will initialize an additional restart after the local cache on the staging slot but as long as you're following best practices that should be fine. So, a couple of follow up questions: If you swap from within the portal, does it take longer than 90 seconds? Did you customize WEBSITE_SWAP_WARMUP_PING_PATH or WEBSITE_SWAP_WARMUP_PING_STATUSES To troubleshoot , check your logs at D:\home\LogFiles\eventlog.xml for any timeouts or routes that may not be returning success codes. If you are using local cache, do you get the same result if you swap without local cache? If not, you may need to rethink your cache strategy.

Azure App Service: Custom Domain for Virtual Application

Accepted answer

Ryan Hill 28,286 Reputation points Microsoft Employee

2022-03-30T19:27:04.14+00:00
Apologies for the delayed response @Mike-E-angelo . As you've discovered, virtual applications can't be bound to a custom domain. Reason being is because the domain is bound to the worker instance that your app service is running on.

Over 90 seconds taken for the swap is definitely something to look into. The operation is pretty straightforward;

apply applicable settings

warm-up the slot with HTTP requests

switch routing after 200

Some things that could impact startup is the usage local cache or a lengthy application startup. The use of local cache will initialize an additional restart after the local cache on the staging slot but as long as you're following best practices that should be fine.

So, a couple of follow up questions:

If you swap from within the portal, does it take longer than 90 seconds?

Did you customize WEBSITE_SWAP_WARMUP_PING_PATH or WEBSITE_SWAP_WARMUP_PING_STATUSES

To troubleshoot, check your logs at D:\home\LogFiles\eventlog.xml for any timeouts or routes that may not be returning success codes. If you are using local cache, do you get the same result if you swap without local cache? If not, you may need to rethink your cache strategy.
Please sign in to rate this answer.
Mike-E-angelo 506 Reputation points

2022-03-31T17:20:49.403+00:00

Thank you for your reply @Ryan Hill . For further context, my deployments were swapping 6 App Services, and they were swapping:

From maintenance (offline) to production

From staging into production

From maintenance into staging

This is obviously for a sophisticated scenario, namely one where the system must be offline to perform database updates and the like. I further modified this workflow so that it's using concurrent agents. It now take 8 minutes for the entire process. This is still a bit of time, but considering this is considered the most involved (and rare) deployment I have, I am OK with this.

For further context, my "usual" deployment that I typically use has 1 App Service swap and that takes about 2 minutes to load it into staging and to perform the swap. So, I am happy with everything as it is now.

Mike-E-angelo 506 Reputation points

2022-03-31T17:22:15.543+00:00

Actually @Ryan Hill there is one question maybe you might be able to assist with. Even with the warmup, on the first request after a swap, it takes about 6-7 seconds for the page to respond. Is that normal?

Ryan Hill 28,286 Reputation points Microsoft Employee

2022-04-05T12:22:26.647+00:00

Apologies for the delayed response @Mike-E-angelo . By default, the request will be made on the application root, therefore, I would consider this normal if your app takes this long to respond. You can use enable Application Insights on your app to see which dependencies are causing that delay if that's not what your expecting. Another option to consider is changing WEBSITE_SWAP_WARMUP_PING_PATH app setting to a page that doesn't do any sort of rendering and just returns basic text.

Mike-E-angelo 506 Reputation points

2022-04-05T14:10:51.477+00:00

Thank you for the confirmation @Ryan Hill . It's not that this is something I was/n't expecting, it's that this is about the same performance experienced when deploying directly into production. The first request takes about 5-6 seconds to "warmup" so I am wondering what the "warmup" is for the swap as it seems like it's not doing anything at all.

Mike-E-angelo 506 Reputation points

2022-04-06T16:48:47.17+00:00

Thank you for the private message @Ryan Hill (making that known so that it doesn't appear I'm talking to myself -- any more than usual!). My last outstanding concern here is that the "warmup" does not appear to be any better than simply deploying to production. Both incur about a 6-7 second wait on the first request. It would seem to me that the swap is making a call to root (which is how I am testing this) and that should be an instant response if it's warmed up.

Thank you for any further assistance you can provide.

Mike-E-angelo 506 Reputation points

2022-04-06T18:30:45.897+00:00

Thank you for your continued assistance @Ryan Hill , it is definitely appreciated. Note that I have not configured swapping in any way as I understand it, it operates exactly as you described and how I understand/expect: do all the magic, and call the root "/". Note that restarting the app does indeed also incur the 6-7 seconds. So, everything does seem to be operating as expected, except for the 6-7 seconds on the swap.

Here's why. If the "warmup" is waiting for the 200 code and it takes 6-7 seconds for the first 200 code THEN the swap occurs, that means the "warmed up" code is in production and hitting that first request should be instant. But it is not. It still takes 6-7 seconds for that load. I am not sure what swapping gets you in face of such performance, except that now you have a backup to swap back to in case there is something wrong with the deployment.

FWIW I am replying publicly to your private comment in case others are facing the same problem here. I guess we should move this to another issue altogether. :P
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Azure App Service: Custom Domain for Virtual Application

0 additional answers

Your answer