I have some tips I’d like to share about the performance of Microsoft Azure B-Series burstable VMs. You’re reading this page served by one…what do you think? Not bad?
Recently, I decided that it was time to rebuild from scratch the newbie VM I’d been running on Azure in the old service model for more than four years. That meant it was time to rethink which cloud VM to use.
Azure (and AWS) offer families of VMs that allow the architect to precisely match the workload to cost and performance parameters. Many architects simply compare cost, memory and CPU specs when selecting which families and members in those families to use.
But it’s a bit of an art to select the correct cloud VM family and size. It’s important to consider CPU internals, including processor family, number of cores and cache size. This is why DevOps should be engaged with application architects: when you are building a cloud infrastructure, you need to know how the app works.
On the old VM, I used a Basic.A2 VM (yes, that old). For this rebuild, I chose Standard_B2s B-series VM. Given that the OS, disk type, file system and patch level was held constant, the much improved performance noted in this VM had to be attributable to the change in virtual processor. (And, possibly to the hypervisor’s approach to dispatching these VMs.)
The burst algorithms vary between Azure and AWS, but the concept is the same: you bank CPU usage until you need it. But there’s an issue: initial performance is unacceptable in a burstable VM that’s just stared because it’s got no credit in the bank. Depending on the rate that credits are applied, you might have to run the VM for hours to reach an acceptable level of performance, especially if the VM’s baseline CPU allocation is small. Baseline CPU allocation is the percentage of the CPU your burstable Azure VM or EC2 instance can get 100% of the time it’s running.
Both AWS and Azure overcome the start-up challenge by providing initial credits so you can get going. AWS’s design actually offers two different kinds of credits with a separate baseline bucket in its T2 burstable EC2 instances. What Azure does isn’t as clear but it’s a good bet it’s doing something similar.
After you’ve picked the B-series VM size in Azure (or for your EC2 instance) it’s very important to monitor it. In Azure, two metrics are specific to B-series VMs: CPU credit consumed and CPU credits remaining. It’s a snap to add a graph of these two metrics on your Azure portal dashboard. This is something you should do as soon as you start the VM.
In the image below, you can see a VM that was launched about 24 hours ago. Note that it was started on a Friday night, local time, to give it the chance to build a bank of credits for Monday morning. Why pick a specific launch time to allow for credit collection? It’s simple: the initial credits you receive when you start the VM are likely to be used to get everything up and going.
This makes burstable instances unlikely to be useful for containers. Think about it: if you use your initial bank up getting the container launched, the app will not perform acceptably.
On the other hand, when you are running a website like this VM does, where arrival rates spike when a new post becomes available or newly popular on Google, having that bank of credits delivers better performance than a fixed CPU size will.
Leave a Reply