1

I'm using Azure REST API to create, deploy and start a Cloud Service (classic) (cspkg hosted in Azure Storage) with hundreds of instances. I'm noticing that time Azure takes to provision and start the requested instances is really heterogeneous. First instances might start in 6-7 minutes but last ones might take up to 15-20 minutes, about 10 minutes longer than first ones. So my questions are:

  • Is this the expected behaviour? If so, what's the logic behind this? Could I do anything to speed things up?

  • How is Azure billing this? Is it counting the total count of instances since the very initial time when Cloud Service is deployed? or is it taking into account the specific timing on each individual instance?

UPDATE: I've been testing more scenarios and I've found a puzzling surprise. If I replace all the processes that my Cloud Service instances should run by a simple wait for some minutes (run .bat file with timeout command) then all the instances start almost at the same time (about 15 seconds between fastest and slowest instance). It was not just luck and random behaviour, I've proved that this behavior is repeatable and I can't even try to explain the root reason.

RubenJMarrufo
  • 179
  • 8
  • *Hundreds* of instances? Yeah, I can imagine that taking a while, given the allocation demands. But... there's no way to answer whether it's expected behavior. Plus, "classic" cloud services are fairly old technology (the guest OS gets periodic updates, but really nothing has changed in the past several years). – David Makogon Feb 08 '19 at 00:25
  • @DavidMakogon - what is the suggested migration path? We have a cloud service that runs 2 instances, and my understanding is that the path forward is Service Fabric? That requires (for best uptime) 5 underlying VM instances. We heavily use sessions with Service Bus, so something like Azure Functions are not feasible. – Brendan Green Feb 08 '19 at 04:00

1 Answers1

1

  • I also checked this a few weeks ago, and the startup time, depends on the size of the machine, if it is large it has more resources, so the boot time is faster, and also, if there is any error, exception on startup the VM will recycle till it can successfully start. I googled it, but did not find any solution to speed this up, so I don't think it is possible to do anything about the startup time. In the background every time when you deploy something, it will create a Windows Server, and boot it up and deploy your package on it and puts your web roles behind load balancer, this is why it takes so long, because a lot of things are happening.

  • The billing part is also not the best for the classic cloud services, you have to pay for it even during the startup and recycle, and even when it is turned off, so if you are done with your update, you should delete the VMs from your staging slot or scale it down, because you will pay for it even if it is turned off.

hujtomi
  • 1,540
  • 2
  • 17
  • 23