Skip to main content


Sitecore Symposium 2017: Sizing Sitecore Deployments on Azure

This session was lead by Ciaran McAuliffe from Sitecore. He talked about several things that impact your monthly Azure bill, how to make sure you are not over paying for services you don’t need, and getting enough server for a performant website. Here are my notes from the session:

    • Data Center Pricing
      • Not the same for every data center
      • Can get a discount with a Microsoft volume license
    • Data Center Availability
      • Not all data centers have all sitecore services
    • ARM Templates
      • Have a default topology but can be changed
      • Make sure your topology matches your needs
    • Sitecore License
      • Can limit what options are available for scaling
    • SQL Server
      • Costed by
        • DTU (data transactional unit)
          • A mix of ram, cpu, i/o
        • Storage amount
      • This is an elastic pool that can automatically scale up and down
      • Not recommended for session state management
    • Azure Search
      • Costed by
        • Storage
        • Number of index nodes
        • Queries per second
        • Search units
          • Must be a divisor of 12
          • A big cost jump between levels
    • Redis Cache
      • Costed by
        • Memory
        • Number of keys
        • Throughput
      • Recommended for session state management
    • App Insights
      • Costed
        • Per GB of data retention
        • Per GB of data exported
      • Not available in all data centers, so it can have latency getting to the nearest data center
        • You must also ensure any liability for data leaving a country if relevant
    • Calculating requests per second
      • Lots of online tools
      • Guessing can cause you to pay more money for compute power you do not use
      • Calculate based on the peak requests per second, not the average
        • Calculating based on the average will cause your site to not respond well during peak times
    • Performance
      • Create web tests in visual studio to get load testing results
      • Respond the results with changes to your environment
        • Be sure to enable caching within Sitecore for common components such as menus, nav bars, and footers.
        • Scale down your environment if caching is able to give you the performance you need.
    • Latency
      • Make sure your web tests take into account network latency and location
      • A test that is fast for you may be slow for your users if they are not close to the data center
        • This can also help you decide to put your content in multiple data centers

I didn’t hear a clear reason why to use redis cache for session state management over sql server. If you have any thoughts on this, leave me a comment below. I’d love to chat with you about it.
Find the rest of my notes from Sitecore Symposium 2017

Leave a 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.

Eric Sanner, Solutions Architect

More from this Author

Follow Us