Why Azure deployment from Visual Studio takes so long?

Question

I created a brand new cloud service with a single worker role using Azure .NET SDK 2.6. The RoleEntryPoint is pretty much empty.

First time it took a while because of VM creation. My expectation is that following publish attempts would be much faster. Turns out it takes at least ~5 minutes. Inspecting deployment activity logs in VS I see:

20:17:06 - Checking for Remote Desktop certificate...
20:17:07 - Applying Diagnostics extension.
20:17:29 - Preparing deployment for AzureCloudService2 - 15/05/2015 20:17:03...
20:17:29 - Connecting...
20:17:29 - Verifying storage account ...
20:17:30 - Uploading Package...
20:17:51 - Updating...
20:19:59 - Instance 0 of role WorkerRole1 is ready
20:20:00 - Starting...
20:20:19 - Initializing...
20:20:19 - Created web app URL: ...
20:20:19 - Complete.

Why on earth it takes 2 minutes to update this app? Is there a way to speed this up?

Answer 1

Turn off MSBuild output.

In Visual Studio go to Options > Projects and Solutions > Build and Run. Set both MSBuild project options to quiet.

When I did this I saw a major decrease in deployment time.

Answer 2

2 to 4 minutes to update the Azure deployment are not that much considering that:

1. It includes uploading the package
2. The package gets copied a couple of times internally until it reaches your instance
3. We effectively mount the package as another disk to the machine
4. Verify that everything is ok
5. Switch your applications to run from the new mounted disk (meaning stopping the old, starting the new one)
6. Unmount the old disk containing the old package
7. Notify that everything is ok

And this is an oversimplification of what is actually going on. All those are happening asynchronously and if it takes like 15-20 seconds for each item, you see my point here.

There are some things you can do if you want faster deployments:

1. Make the size of the package smaller in case you have big files in there. It's better to download your big dependencies from storage during startup, than bundling them in the package
2. If it's a WebRole and you want to test updates fast, you can enable WebDeploy as part of the deployment and then do a normal "Publish.." workflow from within VS. It's just a check box when you publish your package from VS. It takes seconds to update the files after that. Be aware though that for changes you want to persist, you have to update the cloud package by doing a full redeploy, otherwise if the instance gets re-imaged, you'll loose the changes you made. This is basically only for development.
3. If it's a WorkerRole, you can split your loads into processes (simple .exe) that your WorkerRole's EntryPoint downloads from storage, unzips and executes. If you have a newer version, you just upload a new package to storage. Your workerrole simply monitors storage for newer versions of the package and then downloads it, unzips and runs the new .exe file after killing the old one.

Hope it helps.