Open teeto opened 2 years ago
Hi there @teeto!
Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.
We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.
We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.
Thanks, from your friendly Umbraco GitHub bot :robot: :slightly_smiling_face:
Thanks @nzdev but as i understand when i save a document type it is rebuilding all the nucache? Its important to say that it is happening with an empty Umbraco, after creating the first document type and then modifiing it and saving, so its not related to having lots of content. I have tried to remove all my custom code and the issue is still happening
Have also been consistently reproducing this across an ongoing Umbraco 10 build, and it has been making the development experience quite frustrating. Will check back through logs to see if I can provide any useful information to help out!
Hi, I had a similar issue and I found that my laptop memory usage was hitting >92% and my local instance of Umbraco 10 would run really slowly until I could get the memory usage back down below 90%. This usually meant I had to close Visual Studio.
Can you check the memory usage the next time you have this issue?
It seems to happen only on development mode, in production it works fine. I dont think it is a memory issue, i guess it is related to models builder that while set to "Nothing" may be it is doing something in the background which may be rebooting the app. I opened this issue in Umbraco v8 that was a very similar issue: https://github.com/umbraco/Umbraco-CMS/issues/7756
Also having this very frustrating developer experience with v10. Anyone else?
Hey folks, I've been having a look at trying to reproduce this issue, but unfortunately without success, so I've made a little video where I go through it, I'd love to hear if I'm missing something.
It's also worth mentioning that the PR that nzdev mentioned was released with 10.3, so maybe it'll help if you upgrade to the newest version (10.3.2).
Hope to hear from you
@nikolajlauridsen I suspect this wont be apparent till you have many existing documents of that type. Create a few hundred documents of that type. Then modify the document type.
Hey Chad, thanks for the swift response 😄 I got a bit confused since it was mentioned that this happens without having a lot of content.
I tried again, this time with 2k content nodes (looking like the screenshot below, I added the AnotherProp as a test), this time it did indeed take a little longer, but only 1.68 seconds, which is still far from the minutes otherwise reported. So I'm wondering is something else is afoot here? Other than NuCache having to do some rebuilding (By the way, big H5YR for your improvements in this area 🎉)
For my own sake, I'll just add the Notification Handler for creating content here, so I don't have to re-write it in the future 😉
using Umbraco.Cms.Core.Composing;
using Umbraco.Cms.Core.Events;
using Umbraco.Cms.Core.Notifications;
using Umbraco.Cms.Core.Services;
using Umbraco.Cms.Infrastructure.Scoping;
namespace FreshTenTwoOne;
public class ContentCreator : INotificationHandler<UmbracoApplicationStartedNotification>
{
private readonly IContentService _contentService;
private readonly IScopeProvider _scopeProvider;
private readonly ILogger<ContentCreator> _logger;
public ContentCreator(IContentService contentService,
IScopeProvider scopeProvider,
ILogger<ContentCreator> logger)
{
_contentService = contentService;
_scopeProvider = scopeProvider;
_logger = logger;
}
public void Handle(UmbracoApplicationStartedNotification notification)
{
using (var scope = _scopeProvider.CreateScope())
{
for (var i = 1; i <= 2000; i++)
{
var contentName = $"Child {i}";
_logger.LogInformation("Creating: {ContentName}", contentName);
var content = _contentService.Create(contentName, 4061, "test");
content.SetValue("title", contentName);
content.SetValue("bodyText", "" +
@"Cras ultricies ligula sed {shortened for readability)");
_contentService.SaveAndPublish(content);
}
scope.Complete();
}
}
}
public class Comp : IComposer
{
public void Compose(IUmbracoBuilder builder)
{
builder.AddNotificationHandler<UmbracoApplicationStartedNotification, ContentCreator>();
}
}
Thanks @nikolajlauridsen . For reference, I have a site with ~200k nodes of one type. The time scales with the number of nodes of the type. It's basically impossible to use the backoffice or umbraco apis to make changes to the document type. I have to use raw sql to remove / add properties.
I'd recommend using SQL profiler to see what SQL statements run during doc type saving to get more detail on what to optimize. From memory, it's not just the nucache part that's slow.
Yeah, I can see how that'll add up in the end, but I guess in that case, there's not really a silver-bullet fix for the issue other than making NuCache faster, or replacing it (which is on the roadmap).
But regardless I'll bring it up with the team at our next meeting, just to get their input, but I'm afraid that any major NuCache improvements are not really in the cards right now, with Delivery API, EF Core, and new back office being the major projects being worked on right now, if only there were more hours in the day. (PRs are of course always welcome)
But let's see what the team says.
Thanks @nikolajlauridsen. I've done what I can (including a few prs to help with replacing / optimizing how nucache works that were not merged https://github.com/umbraco/Umbraco-CMS/pull/9857). For my vote, I'd take a fix for NuCaches scaling problems any day over replacing NPoco with EFCore given the major problems with NuCache. Given NPoco isn't broken and there isn't really anything fundamentally wrong with it, EFCore is more of a nice to have (and I'm a fan of EF https://github.com/nzdev/Umbraco-CMS/commits/v9/efcore).
I am on the same page as @nzdev here.
I think the caching layer should be fixed in favor of EF Core. Caching issues are already affecting a lot of websites.
Dave
Thanks @nikolajlauridsen for your help.
As i was experiencing the problem, it was happening only in my local machine, an Umbraco installation with very little content amount. Once published to production everything is fine. So i though it had to be with the Runtime Mode = "Development".
But recently i changed my the connection string to the server BD, and the problem is not happening, so it may be related to my local dev BD.
I am using Microsoft SQL Server Developer 15.0.2095.3, 64bit on Windows 10 Pro.
Server collation as "Modern_Spanish_CI_AS".
My connection string is this:
Server=localhost;Database=MyDB;Trusted_Connection=True;TrustServerCertificate=True;MultipleActiveResultSets=True;connect timeout=300;
May be the Developer edition has some limitation that Umbraco is reaching when a modifing document type?
It still happens in Umbraco 11 I have installed a fresh new Umbraco 11 using VS new project and selecting Umbraco template. On database i select custom and paste this string: Server=localhost;Database=dbname;Trusted_Connection=True;MultipleActiveResultSets=True; I am using Microsoft SQL Server Developer 15.0.2095.3, 64bit on Windows 10 Pro. After umbracon installs i manage nuget packets and install: WebEssentials.AspNetCore.OutputCaching Umbraco.StorageProviders.AzureBlob
I create a "Default" template under settings. Then create some document types, go to settings, create new folder "Web" Then create some document types, i create them selecting create and then "Document type" (without template) Create some properties and select "Default" template.
After creating one root content i start having problems editing the document types.
✅ Reproduded on v11 dev (11.5.0 - e6a1640) using SQL Server developer 16.0.1105.1 with the following generation code and the following payload
{
"amount":30000,
"doctypeAliases":["invariantDoctype"],
"containingDoctypeAlias":"container",
"containtingDoctypeUsesListview" : "true",
"newDocTypePropertyMinAmount":20,
"newDocTypePropertyMaxAmount":20,
"languageIsoCodes":["en-us"]
}
Adding a property to this doctype (simple textstring) and hitting save, it took 5.4 minutes for the server to respond on the PostSave
Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)
10.2.1
Bug summary
Create a document type, save. Edit the document type save again. It gets saving for about 1-3 minutes, sometimes more, without errors
Specifics
I dont use Models builder, i have set it to Nothing, but i have tried other values. No errors on screen neither console javascript errors. This is my Umbraco config:
"Umbraco": { "CMS": { "Runtime": { "Mode": "Development" }, "ModelsBuilder": { "ModelsMode": "Nothing" }, "Global": { "UseHttps": false }, "Content": { "MacroErrors": "Throw" }, "Hosting": { "Debug": true }, "RuntimeMinification": { "UseInMemoryCache": true, "CacheBuster": "Timestamp" } } }
Steps to reproduce
My OS is Windows 10 Pro Install lastest visual studio umbraco templates Create new umbraco project using the last version (10.2.1) Select sql server database, my version is SQL Server 14 Create a document type, save. Edit the document type save again. It gets saving for about 1-3 minutes without errors
Expected result / actual result
Save the document type in 2-3 seconds, as when creating it.
This item has been added to our backlog AB#34063