Help, My Azure Site Performance Sucks! — Part 2
Note
You can check out Part 1 and Part 3 of the series here.
Hello and welcome to Part 2 of my “Help, My Azure Site Performance Sucks!” series. In Part 1, I gave you a glimpse into how I go about diagnosing issues when someone reports a problem with their cloud-hosted sites. I really wanted to let you know how I tackle diagnosing an issue and the areas I look into first. In this next article, I want to give you more concrete examples of exactly how you can go about fixing your performance woes.
Performance slowdowns are rarely change-this-one-thing-and-everything-is-awesome scenarios. More often than not, you’re going to need to look at several areas of your environment and Sherlock Holmes your way to a solution. Because there are so many factors in play, small problems get compounded into big ones and start affecting other systems. If Part 1 taught you anything, I hope it’s how to step back and evaluate each piece before you go all Hulk-Mania on your IT guys.
When performance issues arise, they never tiptoe into your organization and whisper that something’s wrong. It’s more like a freight train barreling through the front door. With bees. And the bees have lasers instead of eyes. You get the idea. The impact is immediate and horrible and everyone needs them fixed NOW! As with most things, there are steps you can take right away, and others that will help fix the issue in the long term.
To help with these two timelines, I’ve broken the topics down into distinct areas, with some steps to take in each case. I’ve included suggestions you can use to ease the pain, and long-term solutions to prevent them coming back. So, let’s get to the tips!
The Database Dilemma
As I said before, the database is almost always the issue. Whether it’s bad design or configuration, data-driven sites always seem to fall victim to slow performance when hosting in Azure. The good thing is that problems are usually easy to find and Band-Aid. The bad thing is, you may need to consult a DBA to get your site performing at 100%.
If you see that your DTUs are spiking and want immediate results, simply scale your database to the next tier. It’s a great way to see instant performance improvements. Just be sure to take a seat when the next Azure bill comes in if you scale up to the P2/3 range. This should be considered a temporary fix while you get to the bottom of what is really causing your performance issues.
With detailed knowledge of where your database is having problems, hit up your neighborhood DBA to see what indexes make sense for your application. They love talking about those things and it can have a huge impact on improving your performance and reducing latency. By tuning your database for your exact needs, you’ll get much more efficient processing and a lot fewer DTU spikes. You can even use the Recommendations from the Azure portal to help identify which indexes are good to keep around.
App Service Specs
If your database isn’t the cause of your troubles, take a look at your web server. Is it maxing out its memory or CPU? Are your processes taking forever to complete? Maybe your site monitoring software is blowing up your pager (you still have one, right?) every night. If so, you may need to check out your App Service plan to see the details. Here’s what you can do to help fix your performance issues.
Scaling up your app service plan will allocate more resources to your site, addressing the issue in the short term. Azure has a lot of great tools in the App Service Advisor, which can provide guidance on where your service is having trouble. It’s a great place to start and should be one of the first things you do. If you’re using Application Insights, check out the Slowest Requests report to find out which areas of the site are performing the worst. This information can help you in fixing the bigger issue if your web server is running out of steam.
In the long term, you want to ensure your app service will perform under any load. This means scaling up your number of servers (manually or automatically), and making sure you understand what’s happening with your resources. Set up Alerts in your Azure portal to get notifications for when you run out of resources. 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 here is to monitor your activity! It’s the only way you’ll know how the Website Express is running, and it will give you a glimpse into when it comes off the rails.
Serving Media
If you are still having problems with page loading, it may be due to how you are working with media within your site. There’s about a billion different ways to reference an image, and understanding how to leverage Azure to the fullest will be key for your scenario. You can certainly kill your performance by doing things the wrong way, so solid coding and know-how will go a long way.
For quick results, you should focus on good coding techniques and practices. This means reducing the payload you send to the client and limiting the number of calls. Make sure your images are web sized and leverage CDN-hosted external scripts, if needed. While your marketing may LOVE the idea of loading 100+ 20GB images for your product gallery, those AOL users still in your network won’t think the same way. You need to be sure you’re catering to your audience and their connection speeds, where possible.
If you can, move all your images to Azure Storage, and update your paths to use the full CDN URL. You’ll cut down on the work your web server has to do with serving images, and replicate your content around the globe for super speedy delivery. And don’t forgot to resize your images for mobile devices and small screens! If you’re using a platform for your site like a CMS, this may already be built into the functionality for you.
For your JS and CSS, do whatever you can to reduce their size and the amount of calls. Many browsers limit the number of requests you can make from a single domain, so the fewer in your code, the better. If you‘re using the CDN, be sure you understand 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.
Better Code
If you’ve ruled out the database and the app service, there’s a good chance the problem lies within your code. While the other areas are pretty cut and dry on how to approach them, custom functionality is a bit tougher to diagnose. Hopefully, you have access to your repository and can dig in and check out what’s going on.
These suggestions are really about doing the basics: resolving errors, eliminating variables, and tracking the diagnostics. As with any application, nothing can replace good design and logic, so be sure your site has both. Get an experienced developer to review each piece of custom functionality. If something’s not being used, disable it! There’s no sense in executing a cleanup task when no one uses that section of the site. And if you’re getting errors, you’re making the system do extra work every time it happens. Resolve those ASAP!
To fix code in the long run, you really need to make sure everything is up to date. If you’re using a platform for your application, make sure it’s on the current version and patched. Ensure that you’re calling the database efficiently, pooling requests when you can. And TEST YOUR CODE! Azure gives you Deployment Slots, the Performance Test utility, and Diagnostic Logs to help you ensure your code is running great before it’s ever deployed to Production. Knowing about an issue ahead of time can save a lot of tough conversations and stress ball abuse.
Other Stuff
When it comes to Azure, certain things are exactly the same as any other hosting (file systems, memory, etc.), but some areas have a completely different way in which they work. Things like session management, caching, and infrastructure can have a very different look to them when it comes to cloud. If your code is closely tied to these types of substructures, they can certainly cause a lot of havoc when it comes to assembling the Voltron-esque collection of systems that make up your site.
Azure has a lot of secondary systems that can offload your heavy lifting. From Azure Functions to Logic Apps, the server-less architecture is a great way to improve your site performance while reducing your resource consumption. If you did your Performance & Load Tests, you should know which areas of your site are causing your slowdown. Automate integrations where you can, and get the cloud working for you!
Architecting for the Future
When all’s said and done and you’ve made every improvement you can, you may still find yourself with not-so-stellar site performance. If this is the case, you really need to consider the fact that your application may just need horsepower. If you’ve rolled out your database in an S-0 to save some cash, you’re going to quickly find that no amount of code changes or reconfiguration is going to give you what you need to run smoothly. You need to make sure your application and database have all the resources they need to do the job.
I always recommend at least an S1 App Service Plan for a production site.
Your mileage may vary. However, 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. Depending on your storage and memory needs, Premium may be a better bet, so be sure to monitor your site carefully.
I would always start with an S2 or P1 Azure Database and expect to scale up.
Modern systems have so much read/write activity, 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, the Premium tier may be the best bet, depending on your backup and performance needs.
Use Azure Storage with the CDN.
It’s such a simple solution to storing content that it would be foolish not to use it. With data centers around the world, your content will be cached and delivered faster than a DOS attack on a SQL Server 6.5 instance (As SOON as you brought it online!). Be sure you understand and implement TTLs for your modified files, especially your JavaScript and CSS.
With all architectures, it is important to be flexible.
Your initial configuration may be great for your launch, however, after that well-timed Super Bowl airs, your traffic may go through the roof. Be prepared to adjust your environment as needed. With auto-scaling, your app service can add new servers when it needs them, then scale back down when the hordes move on to the next Internet fad. It’s a great way to control your costs, and keep a little bit of your hair from being pulled out.
Moving Forward
Hopefully, this article gave you some concrete ideas on how to help your Azure sites perform better. Unfortunately, there’s not a Hogwarts’s spell that fixes the problem, but there are several things you can do to set yourself up for success with the right solution from the start. The key is to always be monitoring because performance never stays the same. Azure gives you a ton of tools to track your activity, so be sure to use them! Good luck, friends!
Have some other ideas to improve performance? Why not share them in the comments!
This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.
Follow our publication to see more product & design stories featured by the Journal team.
