Does anyone have any experience to share around the optimum hosting configuration for u13?
Back in u8 it wasn’t recommended to use 64-bit due to memory usage, and obviously now we can host under Linux and save cost against Windows App Services.
Before we jump in, does anyone have any learnings on this, and knows what runs best performance-wise?
13 should be close enough to 9…
That’s really helpful - thanks for posting!
I always recommend P0v3 in production as standard.
The biggest bottlenecks in an Umbraco site are CPU-bound network IO (database and blob storage, if using) and, to a lesser extent, disk speed.
Pv3 app services use faster SSD storage and can have more threads handling IO (per v core) than the alternatives.
So hard to keep up with MS constantly evolving the app service plans..
And prob why Umbraco Docs don’t have a recommendation.. Running Umbraco On Azure Web Apps | Umbraco CMS
Just S2 for AzureSQL, and that’s a little hard to find with all the sql plan options now too.. S2 really being a 50DTU Standard(Budget Friendly) – (the S2 only shows in the cost summary once the DTU option selected..)
MS seems to push the vCore sql options by default.
Database is entirely dependent on the size and structure of a site’s content, there’s no one-size-fits-all for Umbraco.
I usually start at S1 and scale up if necessary if the boot-time bottleneck is too high.
Also always beware that running an upgrade requires exponentially more resources for indexing the database so a site that runs/boots fine on an S1/S2 might need a much higher tier to successfully complete an upgrade.
Sounds like a contribution to the docs then.. 
The minimum recommended Azure SQL Tier is "S2", however noticeable performance improvements are seen in higher Tiers
And it was more a musing that you can’t go into the azure portal and select S2…
I usually avoid P0V3 at all cost. I really find it lacking because of it’s single core. Have a background task, rebuilding indexes or something like that and it’ll slow down significantly. I personally think that P1V3 should be the starting tier.
When it comes to databases though, I usually start at S0.
Yes I noticed the push to vCore a few weeks ago, but it’s hugely expensive and not what we need. I find sharing DBs on an S2 elastic pool works fine (smaller sites and within reasons).
We’re running quite a few sites on P0v3 but they’re fairly small. To be honest I’ve not noticed any real pressure on CPU across any of our app services, but memory is definitely an issue. We’ve had weird errors when there’s not enough headroom and it peaks over 90%. The P1mv3 is a great option now - double the ram for only a few dollars more.
Interesting, that’s not been my experience generally. If I need to go bigger than P0V3 it’s usually down to one of two things:
To scale with content because certain tasks take too long e.g. booting, indexing, any other background task that you’d expect to be ≈ 0(n) for content. Often this goes hand in hand with database scale up.
Thread starvation. Between the synchronous database and filesystem abstractions it’s really easy to run out of threads with Umbraco in Azure. Sometimes you can’t optimize for this, and tuning the thread pool settings only gets you so far, so throwing more cores at the problem might be all you can do.
So good info here about sizing, but specifically is everyone running on 64-bit and Linux without any adverse effects? There’s a lot of money to be saved here!
I’d say that you can stay on 32 bit, until you know you need 64 bit.
Here’s a blog post from Scot Hanselman showing memory usage decrease between 32 bit and 64 bit: Penny Pinching in the Cloud: Your web app doesn’t need 64-bit - Scott Hanselman’s Blog
When it comes to databases, I’d highly recommend looking into DTU based SQL Elastic Pools in Azure. They’re priced well and allow for multiple dbs on a “server” with overlapping DTU usage as well as per database DTU limits.
We’re running everything on Linux Web Apps in Azure. They are 64-bit by default. No issues there.
Thanks for that I’ll have a read.
Yeah EPs are the way to go. Umbraco’s light on the db once content is cached., but you’ve got to have enough capacity to restart all the sites at once (like a host migration) . This is where they all hit the db at the same time and queuing / timeouts can cause chaos.
Wow, I remember when that post was new… it’s now… wait… 10 years old?
Bear in mind the focus in that is on saving money by hosting multiple apps in the same service plan.
If you stay 32-bit when putting your Web Application in the cloud you can fit more applications into a limited space.
That’s probably not that relevant to the vast majority of people hosting Umbraco in production.
It’s important to remember that x64 is a different CPU architecture too, instructions behave differently and there are performance implications beyond simple memory address space to consider - x64 will do some things in one cycle that takes two cycles on x86.
You also need to be careful in case you’ve got dependencies that are shipping different binaries (or other low-level code) for different architectures - there’s some very special “works on my machine” issues that can arise from all your devs running in x64, then production using x86.
This is a bit more nuanced in .NET because of memory management - more memory headroom means less time the CPU spends doing GC, which needs to be part of that equation.
If anyone is unsure, I’d always recommend 64 bit on balance.
If you want to be 100% sure what’s “best” for you. Profile your site under load on both and see which delivers the best performance for your code and content.
@JasonElkin at the risk of taking it slightly off topic - what’s your go to - “put the site under load” tool / solution? I’ve tried a few things in the past and struggle to mimic true visitor behaviour - testing some v16 upgrades.
Steve
We use k6
There’s no sure-fire way to mimic true visitor behaviour, but you can script k6 to carry out complex user journeys, download other page assets, and even run full in-browser tests if you need to.
Cool - that’s what I use and do. Just checking I wasn’t missing out on some magic 