NuCache and very large Enterprise-level websites

[LennardF1989]

As explained here: #13525 and acknowledged on the Roadmap under "Support for Lazy-loaded Content Cache in Umbraco CMS", the current solution for NuCache does not work for very large (Enterprise-level) websites.

One of our clients is pushing Umbraco (v8, for the record) to its absolute limit in terms of size. As described above, at December 5th 2022, we had about 21480 content nodes (each with over 5 variants) and 166193 media nodes. Today, we're already doubling that and rebuilding NuCache went into the 1,5 hour.

We added all kinds of precautions like automated backup- and restore flows on rebuild and site startup, to prevent Umbraco from ever having a reason to rebuild the ContentStores on startup. With our client launching a third website soon, this number of nodes is only going to grow even further.

We anticipate that an upgrade to Umbraco v11 is only going to extend the lifetime of the NuCache solution by a little, but it's a problem that will just keep growing more and more unmaintainable.

With Umbraco pushing for more Enterprise solutions, I feel this is one of the things that should be tackled rather sooner than "Later", as it's a serious problem for any large site. Knowing all this, I'm very hesistant to for example convert large-scale Optimizely solutions to Umbraco, while functionality-wise, Umbraco is totally ready for that.

This discussion aims to see who else is dealing with similar issues, remedies taken, and to just raise awareness that this issue is making us and Umbraco look bad for this particular client and also halts us from even suggesting Umbraco for large websites with a similar amount of expected nodes.

[bergmania]

Hi @LennardF1989.

Thanks for your input. We are aware this is a big concern, but at the same time a fix for this requires a rewrite of one of the most complex parts of Umbraco. So there are no low hanging fruits.

Currently we consider the EOL of AngularJS more important and that's why we mainly focus on replacing this with most of our people.

As soon as this is done, we plan to look into "Support for Lazy-loaded Content Cache in Umbraco CMS".

[landlogicit]

I've been closely following the discussion about caching in Umbraco for sites with a large amount of content, and I'd like to highlight a critical point. When dealing with sites that have hundreds of thousands of pieces of content (for example, a multi-site setup with 20 portals, each holding around 50,000 items, amounting to 1 million pieces of content), a traditional caching strategy can quickly lead to significant resource consumption.

Key Issues:
Excessive RAM usage: Preloading all content into the cache requires a vast amount of memory, especially for large-scale sites. The more content you have, the more RAM is consumed, and this can become unmanageable as the site grows.
High CPU load: Maintaining and updating the cache continuously for such a large dataset can lead to substantial CPU usage, impacting overall site performance.
Possible Solutions:
Lazy-loading cache (deferred loading): Instead of caching all content upfront, consider adopting a lazy-loading strategy similar to WordPress. Content would only be cached when requested, significantly reducing memory consumption and making the system more scalable.

Fragmented or selective caching: By caching content in fragments (e.g., by section or portal), we can optimize memory usage and prevent the entire site’s content from being cached at once. This could be particularly useful in multi-site setups.

Distributed caching: For very large installations, a distributed caching solution (such as Redis or Memcached) could help spread the load across multiple servers, avoiding the need to store everything in the local memory of each node.

External caching providers: Utilizing external caching providers and customizing caching strategies based on site-specific needs (e.g., frequency of content updates, traffic patterns) could further improve performance without overwhelming server resources.

Comparison to WordPress:
In WordPress, caching solutions often rely on lazy-loading content, caching pages selectively, and using external cache providers to improve performance at scale. Implementing similar approaches in Umbraco would make large-scale installations more sustainable and cost-efficient, without the burden of excessive RAM and CPU usage.

In summary, for large-scale sites, moving towards a more dynamic, lazy-loaded, and distributed caching approach is a necessary evolution to ensure both performance and scalability. I'm interested to see how Umbraco will evolve in this area!

[nul800sebastiaan]

Just an FYI: support for lazy-loaded content caching is being worked on right now: https://umbraco.com/products/knowledge-center/roadmap/

[landlogicit]

Thank you for the update regarding lazy-loaded content caching in Umbraco 15, it’s great to see this feature being worked on!

However, I think it's important to acknowledge that not all sites can easily upgrade to newer versions of Umbraco, especially large-scale sites with many dependencies. Upgrading is not always a seamless process, as it often involves third-party packages or custom components that might not yet support the latest version. This could make it impractical for many production environments to upgrade in the near future.

For these cases, where staying on versions 9-14 is necessary, it would be beneficial to discuss optimizations that could help manage content caching effectively, such as archiving older content in a separate table to reduce cache load. This approach could help sites with large amounts of content stay performant without the immediate need for a major upgrade.

While the lazy-loaded caching coming in version 15 is a promising solution, having strategies for managing caching on older versions would still be valuable for many users who are not ready to upgrade due to the complexity of their environments.

I’d be interested in hearing thoughts on how to support these scenarios in versions 9-14 or if there are best practices already in place for handling large content caches in these versions.

[landlogicit]

Optimizing Memory Management in Umbraco 12.x (dotnet 7) for Large-Scale News Content with Custom Archiving and Caching

When managing a large-scale news website with thousands or even millions of articles, the default caching behavior in Umbraco can lead to memory pressure, especially with older articles. By default, Umbraco caches all content in memory, which is efficient for smaller websites but can cause issues for large-scale content repositories like news portals.

For instance, in an online news site, daily articles quickly accumulate, leading to a huge content library. Keeping all of these articles in memory can slow down performance and increase memory usage.

Solution Overview:
To optimize memory management, we can implement an archiving strategy where recent articles (e.g., from the past 2-3 months) are stored and cached in Umbraco, while older articles are moved to a custom database table. These older articles are served on-demand using a custom controller and cached for performance.

We will leverage Umbraco’s IContentFinder to intercept requests for /art/{slug} (for example, /art/natale-oggi) and decide whether to serve content from Umbraco or from an archived database table using IAppPolicyCache.

Supported Versions:
Umbraco 12.x (dotnet 7): Full support for Entity Framework and DbContext to manage custom database interactions.
Umbraco 9.x, 10.x, and 11.x (dotnet 5, 6): These versions use NPoco for custom database interactions. We’ll highlight how to adapt the solution for these versions.
Umbraco 13.x/14.x (dotnet 8): Potential differences regarding database handling and caching strategies will be minimal, but you can expect full backward compatibility with Entity Framework.

Implementation for Umbraco 12.x (dotnet 7)
1. Custom IContentFinder for News Articles (/art/{slug})
We implement an IContentFinder that intercepts requests under /art. If content is found in Umbraco, it will be served from the Umbraco cache. If it’s not found, we pass the request to a custom controller to fetch archived content from the custom database.

using Umbraco.Cms.Core.Routing;
using Umbraco.Cms.Core.Web;
using Umbraco.Extensions;

public class CustomNewsContentFinder : IContentFinder
{
    private readonly IPublishedContentQuery _publishedContentQuery;

    public CustomNewsContentFinder(IPublishedContentQuery publishedContentQuery)
    {
        _publishedContentQuery = publishedContentQuery;
    }

    public bool TryFindContent(IPublishedRequestBuilder request)
    {
        // Get the decoded URL path
        var path = request.Uri.GetAbsolutePathDecoded().TrimEnd('/');

        // Check if the path starts with "/art/"
        if (path.StartsWith("/art/"))
        {
            // Remove "/art/" from the path to get the slug
            var segment = path.Substring("/art/".Length);

            // Use GetByRoute to search for content by its route
            var content = _publishedContentQuery.Content?.GetByRoute(false, $"/art/{segment}", null, request.Culture);

            if (content != null)
            {
                // Set the found content as the published content
                request.SetPublishedContent(content);
                return true; // Content found in Umbraco
            }
        }

        // Let the MVC controller handle it if no content is found in Umbraco
        return false;
    }
}

2. Custom Controller for Archived Articles with IAppPolicyCache
In this example, we’ll compare the slug with the full URL stored in the custom database, and use IAppPolicyCache to cache the results for performance.

using Microsoft.AspNetCore.Mvc;
using Umbraco.Cms.Core.Cache; // For IAppPolicyCache
using System;

public class ArticoloController : Controller
{
    private readonly ArchivioArticoliDbContext _dbContext;
    private readonly IAppPolicyCache _appPolicyCache; // Umbraco's built-in cache

    public ArticoloController(ArchivioArticoliDbContext dbContext, IAppPolicyCache appPolicyCache)
    {
        _dbContext = dbContext;
        _appPolicyCache = appPolicyCache; // Inject Umbraco's cache
    }

    // This action handles archived articles
    [HttpGet("art/{slug}")]
    public IActionResult MostraArticolo(string slug)
    {
        // Define a cache key based on the slug
        var cacheKey = $"ArchivedArticle_{slug}";

        // Try to retrieve the article from the Umbraco cache
        var articolo = _appPolicyCache.Get(cacheKey, () =>
        {
            // If not cached, retrieve the article from the custom database table
            return _dbContext.ArchivioArticoli
                .FirstOrDefault(a => a.Url == $"/art/{slug}"); // Compare with the full URL in the archive table
        }, TimeSpan.FromMinutes(10)); // Cache for 10 minutes

        if (articolo != null)
        {
            // Return the custom view if the article is found
            return View("CustomArticleView", articolo);
        }

        // Return 404 if the article is not found
        return NotFound();
    }
}

Explanation:
IAppPolicyCache: Umbraco's native caching system is used to cache archived articles for 10 minutes, reducing database load.
Entity Framework (DbContext): In Umbraco 12.x, we use Entity Framework’s DbContext to interact with the custom database table containing the archived articles.
Differences for Umbraco 9.x/10.x/11.x (dotnet 5, 6)
In Umbraco 9.x to 11.x, custom database operations would rely on NPoco, as Entity Framework support was not available in these versions. Instead of using DbContext, you’ll need to use NPoco for managing custom database interactions.

Example using NPoco (for Umbraco 9.x/10.x/11.x):
Custom IContentFinder remains the same, as this logic doesn’t depend on the database system.

Controller using NPoco:

using Microsoft.AspNetCore.Mvc;
using Umbraco.Cms.Core.Cache; // For IAppPolicyCache
using NPoco;
using Umbraco.Cms.Infrastructure.Persistence;

public class ArticoloController : Controller
{
    private readonly IAppPolicyCache _appPolicyCache; // Umbraco's built-in cache
    private readonly IScopeProvider _scopeProvider; // For NPoco database interactions

    public ArticoloController(IScopeProvider scopeProvider, IAppPolicyCache appPolicyCache)
    {
        _scopeProvider = scopeProvider;
        _appPolicyCache = appPolicyCache;
    }

    // This action handles archived articles
    [HttpGet("art/{slug}")]
    public IActionResult MostraArticolo(string slug)
    {
        var cacheKey = $"ArchivedArticle_{slug}";

        // Try to retrieve the article from the Umbraco cache
        var articolo = _appPolicyCache.Get(cacheKey, () =>
        {
            // If not cached, retrieve the article from the custom NPoco table
            using (var scope = _scopeProvider.CreateScope(autoComplete: true))
            {
                var sql = "SELECT * FROM ArchivioArticoli WHERE Url = @0";
                return scope.Database.SingleOrDefault<ArchivioArticolo>(sql, $"/art/{slug}");
            }
        }, TimeSpan.FromMinutes(10)); // Cache for 10 minutes

        if (articolo != null)
        {
            return View("CustomArticleView", articolo);
        }

        return NotFound();
    }
}

Key Differences for Umbraco 9.x/10.x/11.x:
NPoco: You’ll use IScopeProvider and NPoco’s database handling methods (e.g., SingleOrDefault) to interact with the custom database instead of Entity Framework’s DbContext.
Scope Management: With NPoco, it’s important to manage database scopes using IScopeProvider to ensure transactions are correctly handled.
(Umbraco 13.x/14.x with dotnet 8)
Entity Framework: It is expected that future versions of Umbraco (13.x/14.x) will continue to support Entity Framework for custom database interactions, so the same approach used for Umbraco 12.x (dotnet 7) should apply.
Caching: No significant changes in caching behavior are anticipated, and IAppPolicyCache is expected to remain the best choice for caching in Umbraco.

Conclusion
This solution ensures efficient memory management in Umbraco by separating recent and archived articles. Recent articles are served from Umbraco’s cache, while older articles are archived in a custom database and retrieved on-demand. By leveraging IAppPolicyCache, performance is optimized, and the database load is reduced. The approach differs slightly for Umbraco 9.x to 11.x (which use NPoco), but remains compatible across versions.

This strategy is especially useful for large-scale content sites like online news portals, where content grows rapidly over time.

This example provides a simple starting point, and we will continue to offer additional code snippets to expand the solution. For instance, we will provide examples on how to manage archived news in the backoffice, code for moving news from active content to an archive, and how to handle URLs for active content while considering archived URLs to avoid collisions or URL navigation issues.