High CPU usage during Azure App Service deployment

Every time when I deploy my ASP.NET service to Azure App Service, the CPU usage of my App Service Plan reaches to 95%. After deployment completes, the CPU usage will be back to normal.

I failed to use the Azure Proactive CPU monitoring tool to collect dump files because the CPU usage of each w3wp process never exceeds 25% (the min CPU usage threshold for dump collection is 50%). However, I got below CPU usage logs from the tool.

Before Deployment - One w3wp process is running and consumes 0% CPU

During Deployment - Multiple w3wp processes are started and each of them consumes 25% of CPU

During Deployment - More w3wp processes are created

Finishing Deployment - Only one w3wp process remains and consumes 0% of CPU

My Azure App service has two deployment slots, however, I do not understand why there are more than three w3wp processes are created during deployment.

Any thoughts on why this is happening? Any suggestion on how to reduce the CPU usage is also welcome! Thanks in advance.

Although you'd intuitively think that only 1 extra instance is created for Slots, the Microsoft documentation here^1 is more complex and involves multiple restarts for each of the Source and Target Slots.

I've tried to summarise it as best I understand. This is for a single app with two Slots. In brackets, I've kept a count of how many instances have been created during the process.

• The original Target Slot app (1)
• Apply the target settings over the Source slot causing it to restart +1 (2)
• If local cache is enabled, restart the Source slot again +1 (3)
• Verify the Source slot is now running with the target settings (3)
• Swap the routing over, so Source becomes Target (3)
• What was previously the Target slot is now the Source slot. Copy the original Source settings over to it, causing a restart of the new Source slot +1 (4)

I count that as 4 different application instances created during a single swap operation. The caveat is that the documentation doesn't mention at which stage it waits for each instance to fully shut down.

So, I think this means there will be at least 2 instances in memory at any given time as a best-case, but possibly up to 4 if it doesn't wait for full shutdowns of each.