I am working to moving a site from v7 to v10 (10.4). Expanding nodes in the content tree is extremely slow in v10. A branch with only 14 child nodes in v10 will take about 10sec to expand, but the same branch of 14 child nodes in the v7 site expands almost instantly.
Does anyone know what changed between the versions that would account for this slowness? Hardware, network and database are similar between the sites. Generally everything in v10 seems a bit sluggish.
Could it be NuCache? The site does have ~150K nodes over all. I have tried to disable NuCache but the site crashes and will not load without NuCache enabled.
I am assuming I have misconfigured something, just not sure what it might be.
I'm not sure on the answer, but I have seen this on v10 sites before (not sure if it is v11 also). A lot of nodes will make the back office slow even if the nodes are not direct children.
One known bug (don't think it is solved) is that parsing a modelsbuilder model as a parameter in an controller action will make it very slow on solutions with a lot of nodes. This is apparently linked to the way ASP.NET validates. You should use the umbraco accessor instead as a workaround. Just to let you know if you might run in to this and go crazy after 5 hours of debugging, been there.
Thanks Roy, glad that I am not the only one seeing this. It is a bit subjective, but I am not seeing the issue in code so much (I do use umbracoContext.PublishedRequest.PublishedContent as much as possible, but good reminder). The issue is mostly in the back office admin. My content editors are complaining that it is harder to use v10 compared to the v7 version due to the sluggishness of the back office. Mostly with the navigation of the content tree, although loading and saving a node in the back office is sluggish as well.
We are seeing the issue local (i9, 32GB) as well as on our servers. We are using a Web App, 8GB of ram and 4 vCores on a Azure database. I have tried increasing the resources on both but still have poor performance. I have been over the Azure setup docs multiple times trying different configuration and cannot figure out why is it so slow.
I did notice, while doing some testing, that the content tree seems to not be using the cache or index, but the database directly (at least that is what is looks like). I made a change in the database to see what would happen and the tree updated but content did not.
We are also seeing CGI application errors when saving content. Content does save, quickly actually, but the button spins for a long time then throws the CGI error.
So, I did find something finally. We did add a custom context menu item for the content tree. I removed that custom item and the tree loading got a lot quicker, by about 10x. Content saves even got quick, going from ~2min to ~5sec. It is still slower than the v7 version of the site but at least now it is usable.
Umbraco 10, Content tree loading is extremely slow.
I am working to moving a site from v7 to v10 (10.4). Expanding nodes in the content tree is extremely slow in v10. A branch with only 14 child nodes in v10 will take about 10sec to expand, but the same branch of 14 child nodes in the v7 site expands almost instantly.
Does anyone know what changed between the versions that would account for this slowness? Hardware, network and database are similar between the sites. Generally everything in v10 seems a bit sluggish.
Could it be NuCache? The site does have ~150K nodes over all. I have tried to disable NuCache but the site crashes and will not load without NuCache enabled.
I am assuming I have misconfigured something, just not sure what it might be.
I'm not sure on the answer, but I have seen this on v10 sites before (not sure if it is v11 also). A lot of nodes will make the back office slow even if the nodes are not direct children.
One known bug (don't think it is solved) is that parsing a modelsbuilder model as a parameter in an controller action will make it very slow on solutions with a lot of nodes. This is apparently linked to the way ASP.NET validates. You should use the umbraco accessor instead as a workaround. Just to let you know if you might run in to this and go crazy after 5 hours of debugging, been there.
Thanks Roy, glad that I am not the only one seeing this. It is a bit subjective, but I am not seeing the issue in code so much (I do use umbracoContext.PublishedRequest.PublishedContent as much as possible, but good reminder). The issue is mostly in the back office admin. My content editors are complaining that it is harder to use v10 compared to the v7 version due to the sluggishness of the back office. Mostly with the navigation of the content tree, although loading and saving a node in the back office is sluggish as well.
Hi Jason,
Can you tell me somting more about your server setup and configuration.
We have several big sites on V10 and are not seeing the issues you are describing.
Dave
Hey Dave,
We are seeing the issue local (i9, 32GB) as well as on our servers. We are using a Web App, 8GB of ram and 4 vCores on a Azure database. I have tried increasing the resources on both but still have poor performance. I have been over the Azure setup docs multiple times trying different configuration and cannot figure out why is it so slow.
I did notice, while doing some testing, that the content tree seems to not be using the cache or index, but the database directly (at least that is what is looks like). I made a change in the database to see what would happen and the tree updated but content did not.
We are also seeing CGI application errors when saving content. Content does save, quickly actually, but the button spins for a long time then throws the CGI error.
So, I did find something finally. We did add a custom context menu item for the content tree. I removed that custom item and the tree loading got a lot quicker, by about 10x. Content saves even got quick, going from ~2min to ~5sec. It is still slower than the v7 version of the site but at least now it is usable.
is working on a reply...