Having the same issues with v17 - Publishing nodes takes upto 10-15s. The new backoffice is a lot more chatty with http requests for shadow dom elements and JS. This really needs to be addressed as it’s impacting the web editor experience, and these are the people who cannot be left hanging around with a laggy back office.
Adding to this.
I am the only person currently working on the site. I am working locally to a remote database. I just saved a page, first save of the day and the site hung for a few minutes finishing up with “Failed to acquire Read lock -333”. Why do you need to have a lock for a Read? Reads are just Reads. I get locking on Writes to ensure you save correctly…but Reads?
The slowness locally is atrocious on 17 
I get it that in some scenario’s the backoffice can be slower, although I have personally not really noticed this. But working with a remote database is really asking for bad performance. It’s just terribly slow by any stretch of the imagination.
I respectfully disagree. Previous versions of Umbraco were super fast. I have written many a script that updates the live database from local host, adding 100s of nodes. Sure. Not as fast as releasing the code and doing it “live” but saving 1 node in U17 can take over 30 seconds sometimes. And the reloading of the tree adds too much time.
I know some devs that swear by a remote database, personally I’ve never found the backoffice responsive enough to use one for development. For reference, I get about 35ms ping to the nearest Azure datacentre from my office.
I don’t think I can see latency vs execution time in Azure but average SQL query execution in a given web app is 2.7ms.
Where this adds up is when multiple SQL queries are executed in short succession.
If newer versions of Umbraco make more SQL queries (and I think it does) then I’d expect to see a performance degradation when using remote databases.
1 Like
Exactly, didn’t have time to respond properly, but this is the essence of what I wanted do say. For instance, Sitecore never really worked well with an external database, making it unbearably slow.
And although I think Umbraco should put every effort into making the CMS as fast as possible, requirements do change. If Umbraco does smaller, but more numerous database calls, this will especially be noticable on a remote database.
1 Like
Yes. One of the major changes I have seen in the API is the move away from a single call to save and publish, to now be .Save() and a . Publish(). I say this from doing it in v16, not tried it in v17, but correct me if I am wrong that won’t have changed? This definitely doubles the Save and Publish button time.
There seems to be a lot less caching of items, basic things that don’t change often. Again I say this just from sitting watching the UI load things that haven’t changed, and it’s like a week in the jail it’s that slow 
And I am excited by the massive changes to the UI, moving away from angular was such an achievement. So I am hoping these things will be worked on over the next few iterations and get back to the awesomeness we all know and love Umbraco to be.
And yes. Sitecore is hellish even when working close to the database (I remember from my time with a well known airline that uses Jesse Glynn’s Hold My Hand song). I will never use it again.
The HybridCache was introduced in Umbraco 15 and that shifted away from: loading everything on boot, to: load the base essentials and lazy fetch the rest them when needed. This significantly reduced boot times, but it also meant that not everything is in the cache from the start.
You can tweak some setting, or choose what to include in the cache on boot, using some settings:
One thing I really think HQ should to better, is provide loading icons and animations in the backoffice when stuff is loading. When calls take a longer time, you don’t always see that it’s actually still working in the background.
That’s great information, thank you. And thanks every for rants and letting me rant ,