So... you’ve migrated your application to Microsoft Azure because you’ve seen the light when it comes to the Cloud. Your hosting app is big enough to mine all remaining BitCoins in existence, and your SQL SaaS database would make Facebook proud. You’ve set yourself up to win...so WHAT GIVES WITH THE PERFORMANCE?
Having been somewhat besotted with Azure for a decade now, I’ve learned a thing or two about the misconceptions of Azure performance, as well as some great ways to find out what’s causing it, and can offer some handy tips to get your site running easy breezy in Microsoft’s Cloud.
Full disclosure: Azure and I are in a long-term relationship—a deep, loving, and symbiotic partnership. Truth be told, I have been obsessed with her since 2008. To prove my devotion, I have been creating applications for her, writing articles about her, and holding bootcamps at which she is the sole topic. There’s not a friend, colleague, family member, barista, playground parent, familiar face on the bus, or neighbor’s pet with whom I haven’t shared my amazement for Azure and what you can achieve with her. I like to assume she feels the same.
But during this long affair, I’ve had to admit that no one is perfect. Running in the Cloud doesn’t always go smoothly. In fact, for technology touted as the end to all your problems, I’ve heard more than a few cries of despair from superhero developers who sit baffled by the seemingly inexplicable sluggishness of their deployments.
Well, when your application, with a speed that lightning would be proud of, is deployed to Azure and then whines it’s way up to an astonishing 14.4 K... you’re going to want a divorce. It’s not worth the hassle.
Oh, but it is. Take it from me. So here are some things I work with my clients on to find the source of the speedphobia that Azure seems to invoke.
Are You Azure You Know What You’re Doing?
In my experience, more often than not, the reason for bad Azure performance is lack of knowledge. Why? Because it is huge and complex and isn’t just one thing but a growing list of hundreds. It’s infrastructure, connectivity, functionality, scalability, and flexibility, all rolled into one. It has vast capabilities, and understanding all the individual pieces can be a frightening task, especially if you’re new to the game.
It’s why, when I start diagnosing problems for clients, I begin by finding out how much experience they have with it. Do they get why cloud computing exists? Do they know the difference between Cloud Services and App Services? Did they migrate their app to the Cloud, or was it cloud-architected from the beginning? Did they have Azure expertise on-tap or was it more of a learn-on-the-job job?
So the question isn’t designed to humiliate or patronize, but to take the sheer daunting complexity of the platform seriously and to ascertain why a particular architecture or configuration was chosen—something that can lead to seriously long application loading times if not done correctly.
Avoid Insanity—Remove the Variables
Insanity is hunting through 100 variables in your environment for the cause of bad performance. Eliminate the riffraff and focus on asking the right questions.
Any developer who has spent time hunting the bug that only Linda in accounting seems to conjure will know that a pragmatic approach is the only one. But knowing what not to spend time on can be one of the best steps you take toward getting your performance issues resolved.
If you have multiple apps on the same server, isolate them to their own instances. Get your application database and storage in the same region. Reduce your search by asking questions like: Does the issue only happen to authenticated users? Does it only occur on a specific area of the site? What common denominators can point me to the source?
Dig a Little Deeper
So, once you’ve ascertained that your team is Azure savvy and that you’ve removed as many variables as you can, you need to start trying to identify where the problem is.
It could be that it’s just a single factor in the environment causing the problem. But if that’s how your luck rolls, stop what you’re doing and go and buy a lottery ticket.
In the meantime, the rest of us will have to accept that there are likely several components causing us grief, and we’ll just have to figure out which ones. We’ll also have to get ourselves prepared for change, probably multiple changes as there are frequently several aspects of the deployment that contribute to a slowdown.
Thankfully, working out if the web server (App service) is the root of the problem is somewhat simple: check whether you’re getting spikes in CPU or memory in the Azure portal. If your app is causing your server to max out regularly, you need to think about scaling up or out—which is one of the best things about Azure; scaling is quick and even automatic if needed. Check your App Service plan settings and adjust till you get the performance you’re after.
Unfortunately, App service is rarely the cause of the problem. It’s much more likely to be a data-and/or architecture-related issue. So if your server CPU looks like the Salar de Uyuni salt flats, it’s time to keep searching.
SQL Database, Azure SQL, SQL Azure, and SQL Database for Azure... the many names for a truly awesome and scalable SQL environment. Your data is automatically replicated on the backend for DR, you can easily deploy your database via SSMS, you can connect your website in seconds.
But to ensure that everyone on the platform is getting what they pay for, Microsoft uses DTUs (Database Throughput Units) to work out what resources your database is consuming.
Ah, DTUs. Little vermin. Not a single measurement, but a collection of variables, DTUs calculate CPU, memory, and read-write rates. So when an Azure site is performing badly, DTU spikes are the top suspect. An overworked SQL Database can slow down any application—whether due to long-running queries, poorly-performing indexes, or just bad code causing too many calls.
So if yours is struggling, head over to the Support & Troubleshooting pages of the Azure portal for the tools that can help you work out which queries are taking up the most time and when it is your DTUs are spiking.
DTUs are the most common culprits to poor performance I’ve seen.
Don’t Let Images Slow You Down
This relates to the lack-of-knowledge point I made earlier. Azure offers unique capabilities when it comes to media that developers just aren’t leveraging. Because Azure Storage (which includes Azure CDN) is so easy to configure, developers should be rethinking the performance-sapping “deploy-with-site” model and have their images stored and served from a global network of data centers instead. This can speed up load time drastically throughout your site.
What’s more, by offloading your images to the CDN, fewer calls are made to your main URL to load content, which improves parallel request management.
It’s Not You, It’s Me
If a site is still slow once all the architecture areas have been addressed, it’s time to look at custom functionality. This is where things can get tricky and time consuming.
If you’re using a third-party platform for your website, it’s highly likely that your custom code is the villain. Platform vendors will have ensured the vanilla version of their product runs in any environment, so first make sure your code base is up to date with the latest fixes and then start rummaging around your functionality for the culprit.
Ensure you’re accessing your data in the most efficient way possible. Leverage caching and vendor APIs to store data. Reduce overall payload by only pulling back the data you need. Look for wormhole-producing actions in your functionality like trying to divide by zero.
You’re going to need to take a fine-tooth comb to your code and optimize everything—not an easy task or a quick one. But no cutting corners—be diligent. Check everything with a database connection, memory access, or functionality that relies on external systems. Improve speed and latency by leveraging Azure caching and storage. Do one thing at a time. Patience.
Mulling Time Required
OK, so you’ve probably got enough to think about for a bit. I can hear your brain calculating all the possible things you may have to update, configure, and rework within your site (and silently screaming). So, I’m going to leave you with those thoughts for now, but in my next article, I’m going to make recommendations for how you should architect your Azure applications to minimize performance issues in the future. I guess that would have been more timely when you started working with Azure... but it will also be full of tips on the steps you can take to identify issues, implement stop-gap solutions, and build better Azure sites.
Till next time, friends.
Let me know all your Azure woes in the comments section below, I promise not to blush. I love hearing about workarounds. Or maybe you have had a lightbulb moment, or even two. Share, share, share!
At Kentico, we love all things Azure. Check out how we leveraged Azure Search in Kentico 11 to put some serious searching power into your toolbox!
Creating an MVC Widget Showcase Site with Kentico EMS and MVC – Architecture Updates
Mar 21, 2019 • 10 minute read
Creating an MVC Widget Showcase Site with Kentico EMS and MVC – Custom Widgets and Inline Editors
Feb 21, 2019 • 12 minute read