I was doing a bit of reading on V17 and found this blog post with a few highlights:
Most notably for me it was this statement:
Native AOT Support for Umbraco
Native AOT delivers:
Ultra-fast startup
Smaller application footprint
Better cloud hosting performance
Does anyone know if this is actually possible in V17?
I very quickly spun up a 17.2.2 project and enabled native AOT without any modifications.
Lots of errors and warnings and the project for sure did not want to run
However, I have very little experience with native AOT but the concept seems interesting.
I do have some skepticism as this seems like quite a big ask for a project with this many dependencies and areas I don’t think really plays nicely with AOT compilation.
So my question is, have anyone tried this and/or know if it’s actually possible?
@Saeve even if the MVC thing got fixed, don’t see it happening anytime soon the composer system does runtime assembly scanning at startup which is just fundamentally at odds with AOT. Examine/Lucene is the same story.
And Umbraco is still in the middle of the NPoco → EF Core migration, so AOT isn’t even worth thinking about until that’s done . (targeting Q4 2026 per their roadmap)
Thanks for chiming ind and confirming what I thought!
A bit of a curve ball on this, but still in the same line, what about Ready To Run compilation?
I’ve tested this on a simple Umbraco 17 project I just made and also a big prod project with real prod code and content(not in prod ofc.)
It does actually seem to do some AOT complication, Umbraco can boot and I see no real problems so far.
Do you, or anyone else, perhaps have any insight or knowledge about R2R and Umbraco?
No biggie and of course not something I expect.
I’m just curious if there would be significant gains for Umbraco platforms running in Docker.
I do notice some long cold starts and would love investigate cheap options to squeeze some more performance out of a running platform.
Might try to do a hail marry on my hobby website and just switch it over publish as R2R.
I would be curious too, but I think we’re relying on a few esoteric things, most notably Examine probably and NPoco as well.. That should stop most of these optimizations cold in it’s tracks.
Speaking of slow startups: it is imperative that Examine data doesn’t get destroyed when you restart Docker, it should be in a volume for example. This is most likely the cause of slow startups.
At a recent meetup I’ve seen Umbraco in Docker start within 1-3 seconds, so it can be very fast right now.
Isn’t volume mounting Examine a cause of index corruption and plain just asking for trouble?
I distinctly remember that it has some known issues which is why ExamineX exists.
I would love to discuss cold start optimizations but that might be too far from this topic.
I would hope not, we seem to recommend this in the docs:
The problems you remember might be more for Azure where apps can just disappear, I was hoping if you do docker compose down it would at least do it a bit more smoothly. But now I’ve reached the limits of my knowledge, so I’ll bow out of that conversation.