Welcome back. I trust you’ve had chance to assimilate the information offered in part 1 and that you feel more prepared to tackle diagnosing the causes of performance issues in Azure. In this article, I want to give you more concrete examples of exactly how you can go about fixing your performance woes.
Regrettably, performance slowdowns fixed by changing just one thing are rare. With so many factors in the mix, one thing affects the next—compounding the problem—and, more often than not, you’re going to have to Sherlock Holmes your way through several areas of your environment in search of a solution.
As we all know too well, a performance issue doesn’t flutter in and land gently on our shoulder; it swoops in like an Obsurist in a tornado. It’s easy at times like this to react with mild to manic panic. And with good reason: those issues need to be fixed NOW. But we also have to think long term and get to the cause of the problem. So, let’s look at tips for both—immediate remedies and those for long-term health.
Database in Distress?
As already established, the database is frequently the issue—data-driven sites always seem to fall victim to slow performance when hosting in Azure. The happy news is that we can almost always find a Band-Aid to fit. The mildly annoying news is that to get your site performing at 100%, you might need to consult a DBA.
If your DTUs are spiking and you want to see instant performance improvements, simply scale your database to the next tier. But consider this a temporary fix while you get to the bottom of the issue. And do be sitting down when your next Azure bill comes through... especially if you’re scaling up to the P2/3 range.
With a clear idea of where your database is having problems, talk to your DBA to see what indexes make sense for your application and get rid of the rest. Use the Recommendations from the Azure portal to help identify which indexes you might want to keep. Tuning your database for your exact needs can have a huge impact on improving your performance and reducing latency. You’ll get much more efficient processing and a lot fewer DTU spikes.
Still Not App-y with Performance?
If your database gets a clean bill of health, it’s time look at your web server. Is it maxing out its memory or CPU? Are your processes taking an eternity to complete? Could your site monitoring software be blowing up your pager every night? If so, you may need to explore your App Service plan to view the details. Here’s what you can do to help fix your server-induced performance issues.
Web — Quick Fix
A quick and easy way to fix the issue in the short term is to allocate more resources to your site by scaling up your App service plan. One of the first things you should do, however, is head to Azure’s App Service Advisor. It offers a lot of great tools that provide guidance on where your service is having trouble. If you’re using Application Insights, check out the Slowest Requests report to find out which areas of the site are performing the worst, as this knowledge can help you when tackling the bigger issue if your web server is running out of steam.
Web — Long-term Fix
For the long term, you want to make sure your app service will perform under any load. This means manually or automatically scaling up your number of servers and making sure you understand what’s happening with your resources. Setting up Alerts in your Azure portal for notifications when you run out of resources is a good idea. If you’re using multiple servers and sessions, you should be using Azure REDIS Cache, so be sure to scale that up with the service plan, if needed. The main thing is to monitor your activity so you’ll know how your website is running, and what’s happening when it slows to a crawl.
Is Performance Media-ocre?
If page load times are still causing you grief, it may be due to how you are working with media on your site. Understanding how to leverage Azure to the fullest is key. You can kill your performance by doing things the wrong way; so solid coding and know-how are paramount.
Media — Quick Fix
For quick results, you should look at ameliorating good coding techniques and practices, i.e., reducing the payload sent to the client and limiting the number of calls. Ensure your images are sized for the web and leverage CDN-hosted external scripts, if needed. While the 100+ 20 GB images in the product gallery may be the marketing team’s pièce de résistance, the AOL users still in your network won’t feel the same. You need your focus to be on catering to your audience and their connection speeds.
Media — Long-term Fix
If possible, move all your images to Azure Storage and update your paths to use the full CDN URL. This will significantly cut the work your web server has to do when serving images and enables replication of your content around the globe for super speedy delivery. If you’re not using a CMS that offers built-in image resizing, don’t forget to adjust your image sizes for mobile devices and small screens!
Do whatever you can to reduce the size of and number of calls for your JS and CSS. As many browsers limit the number of requests you can make from a single domain, the fewer present in your code, the better. If you’re using the CDN, make sure you understand the Time-To-Live (TTLs) settings so that your content is cached correctly. If you have frequently changing scripts, you will want to make sure your updates are propagated correctly.
Are You Talking in Code?
If you’ve managed to rule out the database and the app service as suspects, then there’s a good chance the problem is in your code. Diagnosing custom functionality is tougher than other areas, so hopefully, your repository is at hand for you to dig in and check out what’s going on.
Code — Quick Fix
Quick fixes in this scenario take us back to the basics: resolving errors, eliminating variables, and tracking diagnostics. Make sure your site has good design and logic, and have an experienced developer review each and every piece of custom functionality. Disable anything not being used. There’s no point executing a cleanup task when no one uses that section of the site. And remember, receiving errors is a sign you’re making the system do extra work, so resolve those ASAP!
Code — Long-term Fix
Looking long term, you really need to make sure everything is up to date and that any platforms you use for your application are on the current version and patched. Ensure that you’re calling the database efficiently, pooling requests when you can. And TEST YOUR CODE! Leverage Azure’s Deployment Slots, Performance Test utility, and Diagnostic Logs to help ensure your code is running beautifully—something you can do before it’s even deployed to Production. Knowing about an issue ahead of time can save a lot of unpleasant conversations and headaches.
With Azure, certain things (like file systems, memory, etc.) are exactly the same as with any other hosting, but some areas work in a completely different way. Things like session management, caching, and infrastructure can look very different when it comes to the Cloud. If your code is closely tied to these types of substructures, they can cause a lot of chaos when it comes to assembling the collection of systems that make up your site.
Other stuff — Long-term Fix
Azure offers a whole host of secondary systems that can offload your heavy lifting, like Azure Functions and Logic Apps. The server-less architecture is great for improving your site performance while reducing resource consumption. Your Performance & Load Tests will have informed you about which areas of your site are causing your slowdown. Automate integrations where you can. Make the most of the Cloud!
Architecting for the Future
If you’ve got this far and made every improvement you can, but still find yourself with less-than-spectacular site performance, you really have to consider the fact that your application may just need horsepower. If you’ve saved cash by rolling out your database in an S-0, you’ll soon find that no amount of code changes or reconfiguration is going to give you what you need to run smoothly. Your application and database have to have all the resources they need to do the job.
Choose at least an S1 App Service Plan for a production site.
I have found that starting with the Standard tier and working your way up is a good method when spec’ing out your web server. But monitor your site carefully: depending on your storage and memory needs, Premium may be a better fit.
Start with an S2 or P1 Azure Database and expect to scale up.
Modern systems have so much read/write activity, that the lower tiers (Basic / Standard 0/1) just don’t have enough DTUs allocated to keep up with the demand. By starting with S2+, you should be better suited for a “standard” application. Again, depending on your backup and performance needs, the Premium tier may be the best bet.
Use Azure Storage with the CDN.
With all architectures, it is important to be flexible.
Your initial configuration may be perfectly pitched for your launch, but that video of the CEO playing golf in his pajamas may send your traffic through the roof. So be prepared to adjust your environment when needed. With auto-scaling, your app service can add new servers when needed and then scale back down when the masses move on to the next Internet craze. It’s a great way to control your costs while not missing out on sudden surges in traffic.
Hopefully, this article will have given you some concrete ideas as to how to help your Azure sites perform better. Unfortunately, no Hogwarts spells work (I’ve tried), but now you have several tips and tools for setting yourself up for success. The key is to always be monitoring (as performance is an ever-changing beast) and make use of the ton of cool tools Azure offers to track your activity.
Good luck, friends!
Got other ideas to improve performance? Why not share them in the comments!
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!