Skip to content
The Bits That Byte
  • About
January 11, 2020 / Azure

Slow Sitecore PaaS? Check the DTUs and Use Elastic Pools

A slow Sitecore PaaS environment is more than just the Web Apps. The backend is just as important as the front end. If this is not properly scaled, you will run into limitations.

Consider Elastic Pools

As a best practice, you should group your Azure SQL databases into Elastic Pools and provide an overhead large enough for the group. This ensures that a smaller database has enough flex room. It also reduces the amount of governance required for managing DTUs per database as this can now be set at the pool level.

Check out the managing and scaling Azure SQL databases guide with Elastic Pools document from Microsoft.

Per sizing, you will want to check the total or average usage all of the databases you want to add into a pool, and use the larger value. An as example, review the table below:

Database NameAverage Usage (DTU)Max Usage (DTU)
Core510
Master1020
Web2025

The total average usage is 35 DTU, but the max usage is 55 DTU. Take this number and make your Elastic Pool holding these databases greater than 55 DTU. To be safe, ensure enough overhead over the max. I prefer 30% over and would use Azure SQL Database alerts to monitor the databases.

As far as how you group the databases, there are several options. By workload is a common approach where the Web and front end databases are in a pool, operational databases (think core, master, exm, processing, reporting) in another, xConnect and Cortex together, and Commerce databases in a final pool. The key is to test and determine what is governable for you.

Monitor Your Elastic Pool

Monitoring your Elastic Pool is a critical activity. There are a lot of great tools within Azure to do so.

On the Elastic Pool itself, you can review the overall pool resource utilization. You can further drill down into the database resource utilization to view average and max DTU.

As Sitecore is an ever changing environment, depending on user load and any new code, its critical to keep an constant eye on what impacts these changes have on your overall system health. View the “Monitor an elastic pool and its databases” article for more options .

Its Not Just DTUs

At the varying levels of eDTUs, there is also a max storage per pool and maximum databases depending on the basic, standard, and premium tiers. As an example, a Standard 100 eDTU pool allows for a max storage of 750 GB, but only provides 100 GB out of the gate without paying more for additional storage in addition to the eDTU cost.

So if you only need 50 DTUs but have 200 GBs of data, you would need to either go to a larger pool or pay for additional storage. In the unlikely case that you need more than 200 databases at the the Standard 100 eDTU pool level, you would also need to move up to a higher eDTU pool.

Pricing and levels can be found using the Azure SQL Pricing Tool (select the DTU option)

What About vCore?

DTU based Elastic Pools are not the only option… there are vCores. vCore align more the traditional on premises SQL model in that instead of DTUs, you have Cores and RAM. There are still a max number of databases per the offering but it offers more control.

Pricing and levels can be found using the Azure SQL Pricing Tool (select the vCore option). Note that in both options, the pricing will vary by region.

Any Other Cool Elastic Pool Features?

Beyond just grouping the databases together, there are several strong Elastic Pool features. You can run elastic jobs to help with managing a large number of databases. Point in time restore allows recovery, while Geo-restore and active geo-replication offer additional levels of data security.

What Do I Do Next?

Before you move your databases into an Elastic Pool and set the max DTU value, you need to determine if your custom code is part of the reason the Sitecore databases have so much load.

Its not so much that you may have “bad code” (hint, check for bad code!), but knowing that even with the same amount of users, once you add or change code, the backend will get affected.

It’s akin to a bunch of people grabbing shopping carts at the grocery store… depending on how much they put in their cart… it will cause a longer checkout for everyone.

Post navigation

Previous Post:

Planning for Sitecore SaaS

Next Post:

Find Your Sitecore Version Number Without Logging into the CMS

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Sitecore Technology MVP

Categories

  • AngularJS
  • Azure
  • CSS3
  • HTML5
  • Hyper-V
  • JavaScript
  • jQuery
  • OneDrive
  • PowerShell
  • Responsive Web Design
  • Search
  • SEO
  • SharePoint
  • Sitecore
  • SQL 2008 R2
  • SQL 2012
  • Tech Review
  • Tech Toy
  • Technical Resources
  • Uncategorized
  • Visual Studio
  • Web Content Management
  • Windows 8
  • Windows 8 App
  • Windows App
  • Windows Server 2008 R2
  • Workflow

Sponsored Links

Recent Posts

  • Autofail: A Big Azure Autoscale Limitation and What To Do
  • Got Fixes? A Sitecore Troubleshooters Guide to Sitecore Hotfixes
  • Sitecore 10 Application Roles, Storage Roles, and Indexes
  • Don’t Copy Sitecore Databases Across Environments, Sync Instead
  • Hey Sitecore PaaS! Where are My Modules?

Blogroll

  • Colins Sitecore Tech Blog
  • Sitecore Architecture – Grant's Sitecore Rants
January 2021
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031
« Dec    
© 2021 thebitsthatbyte.com - Powered by SimplyNews