Umbraco CMS
CloudHeartcoreDXPMarketplace
14.latest
14.latest
  • Umbraco CMS Documentation
  • Legacy Documentation
    • Our Umbraco
    • GitHub
  • Release Notes
  • Contribute
  • Sustainability Best Practices
  • Fundamentals
    • Get to know Umbraco
    • Setup
      • Requirements
      • Installation
        • Install using .NET CLI
        • Running Umbraco in Docker using Docker Compose
        • Install using Visual Studio
        • Local IIS With Umbraco
        • Install using Visual Studio Code
        • Installing Nightly Builds
        • Running Umbraco on Linux/macOS
        • Unattended Installs
      • Upgrade your project
        • Version Specific Upgrades
          • Upgrade from Umbraco 8 to the latest version
          • Migrate content to Umbraco 8
          • Minor upgrades for Umbraco 8
          • Upgrade to Umbraco 7
          • Minor upgrades for Umbraco 7
      • Server setup
        • Running Umbraco On Azure Web Apps
        • Hosting Umbraco in IIS
        • File And Folder Permissions
        • Runtime Modes
        • Umbraco in Load Balanced Environments
          • Load Balancing Azure Web Apps
          • Standalone File System
          • Advanced Techniques With Flexible Load Balancing
          • Logging With Load Balancing
    • Backoffice
      • Sections
      • Property Editors
        • Built-in Property Editors
          • Checkbox List
          • Collection
          • Color Picker
          • Content Picker
          • Document Picker
          • DateTime
          • Date
          • Decimal
          • Email Address
          • Eye Dropper Color Picker
          • File Upload
          • Image Cropper
          • Label
          • Markdown Editor
          • Media Picker
          • Member Group Picker
          • Member Picker
          • Multi Url Picker
          • Repeatable Textstrings
          • Numeric
          • Radiobutton List
          • Slider
          • Tags
          • Textarea
          • Textbox
          • Toggle
          • User Picker
          • Block Editors
            • Block Grid
            • Block List
          • Dropdown
          • Rich Text Editor
            • Rich Text Editor Configuration
            • Rich Text Editor Styles
            • Rich Text Editor Plugins
            • Blocks in Rich Text Editor
      • Login
      • Document Blueprints
      • Sidebar
      • Log Viewer
      • Language Variants
      • Settings Dashboards
    • Data
      • Defining Content
        • Default Document Types
        • Document Type Localization
      • Creating Media
        • Default Data/Media Types
      • Members
      • Data Types
        • Default Data Types
      • Scheduled Publishing
      • Using Tabs
      • Users
      • Relations
      • Dictionary Items
      • Content Version Cleanup
    • Design
      • Templates
        • Basic Razor Syntax
        • Razor Cheatsheet
      • Rendering Content
      • Rendering Media
      • Partial Views
      • Stylesheets And JavaScript
    • Code
      • Service APIs
      • Subscribing To Notifications
      • Creating Forms
      • Debugging
        • Logging
      • Source Control
  • Implementation
    • Learn how Umbraco works
    • Routing
      • Controller & Action Selection
      • Execute Request
      • Request Pipeline
    • Custom Routing
      • Adding a hub with SignalR and Umbraco
    • Controllers
    • Data Persistence (CRUD)
    • Composing
    • Integration Testing
    • Nullable Reference Types
    • Services and Helpers
      • Circular Dependencies
    • Unit Testing
  • Customizing
    • Extend and customize the editing experience
    • Project Bellissima
    • Setup Your Development Environment
      • Vite Package Setup
    • Foundation
      • Working with Data
        • Repositories
        • Context API
        • Store
        • States
      • Contexts
        • Property Dataset Context
      • Umbraco Element
        • Controllers
          • Write your own controller
      • Sorting
      • Routes
      • Icons
      • Backoffice Localization
      • Terminology
    • Extension Overview
      • Extension Registry
        • Extension Registration
        • Extension Manifest
      • Extension Types
        • Menu
        • Header Apps
        • Icons
        • Modals
          • Confirm Dialog
          • Custom Modals
          • Route Registration
        • Bundle
        • Kind
        • Backoffice Entry Point
        • Extension Conditions
        • Dashboards
        • Entity Actions
        • Entity Bulk Actions
        • Entity Create Option Action
        • Trees
        • Global Context
        • Section Sidebar
        • Section View
        • Sections
        • Workspace Context
        • Workspace Views
        • Workspace Actions
        • Localization
      • Extension Kind
      • Extension Conditions
      • Custom Extension types
    • Sections & Trees
    • Searchable Trees (ISearchableTree)
    • Property Editors
      • Property Editors Composition
        • Property Editor Schema
        • Property Editor UI
      • Property Value Converters
      • Property Actions
      • Integrate Property Editors
      • Tracking References
      • Content Picker Value Converter Example
      • Property Dataset
      • Integrate Validaction
    • Workspaces
    • Umbraco Package
    • UI Library
  • Extending
    • Build on Umbraco functionality
    • Health Check
      • Health Check Guides
        • Click-Jacking Protection
        • Content Content Security Policy (CSP)
        • Content/MIME Sniffing Protection
        • Cross-site scripting Protection (X-XSS-Protection header)
        • Debug Compilation Mode
        • Excessive Headers
        • Fixed Application Url
        • Folder & File Permissions
        • HTTPS Configuration
        • Notification Email Settings
        • SMTP
        • Strict-Transport-Security Header
    • Language Files & Localization
      • .NET Localization
    • Backoffice Search
    • Creating a Custom Database Table
    • Embedded Media Providers
    • Custom File Systems (IFileSystem)
      • Using Azure Blob Storage for Media and ImageSharp Cache
    • Configuring Azure Key Vault
    • Packages
      • Creating a Package
      • Language file for packages
      • Listing a Package on the Umbraco Marketplace
      • Good practice and defaults
      • Packages on Umbraco Cloud
      • Installing and Uninstalling Packages
      • Maintaining packages
      • Create accessible Umbraco packages
      • Example Package Repository
  • Reference
    • Dive into the code
    • Configuration
      • Basic Authentication Settings
      • Connection strings settings
      • Content Dashboard Settings
      • Content Settings
      • Data Types Settings
      • Debug settings
      • Examine settings
      • Exception filter settings
      • FileSystemProviders Configuration
      • Global Settings
      • Health checks
      • Hosting settings
      • Imaging settings
      • Indexing settings
      • Install Default Data Settings
      • Logging settings
      • Maximum Upload Size Settings
      • Models builder settings
      • NuCache Settings
      • Package Migration
      • Plugins settings
      • Request handler settings
      • Runtime settings
      • Security Settings
      • Serilog settings
      • Type finder settings
      • Unattended
      • Web routing
    • Templating
      • Models Builder
        • Introduction
        • Configuration
        • Builder Modes
        • Understand and Extend
        • Using Interfaces
        • Tips and Tricks
      • Working with MVC
        • Working with MVC Views in Umbraco
        • View/Razor Examples
        • Using MVC Partial Views in Umbraco
        • Using View Components in Umbraco
        • Querying & Traversal
        • Creating Forms
      • Macros
    • Querying & Models
      • IMemberManager
      • IPublishedContentQuery
      • ITagQuery
      • UDI Identifiers
      • UmbracoContext helper
      • UmbracoHelper
      • IPublishedContent
        • IPublishedContent Collections
        • IPublishedContent IsHelpers
        • IPublishedContent Property Access & Extension Methods
    • Routing & Controllers
      • Custom MVC controllers (Umbraco Route Hijacking)
      • Custom MVC Routes
      • Custom Middleware
      • URL Rewrites in Umbraco
      • Special Property Type aliases for routing
      • URL Redirect Management
      • Routing in Umbraco
        • FindPublishedContentAndTemplate()
        • IContentFinder
        • Inbound request pipeline
        • Outbound request pipeline
        • Published Content Request Preparation
      • Surface controllers
        • Surface controller actions
      • Umbraco API Controllers
        • Porting old Umbraco API Controllers
    • Content Delivery API
      • Custom property editors support
      • Extension API for querying
      • Media Delivery API
      • Protected content in the Delivery API
      • Output caching
      • Property expansion and limiting
      • Additional preview environments support
    • Webhooks
      • Expanding Webhook Events
    • API versioning and OpenAPI
    • Searching
      • Examine
        • Examine Management
        • Examine Manager
        • Custom indexing
        • PDF indexes and multisearchers
        • Quick-start
    • Using Notifications
      • Notification Handler
      • CacheRefresher Notifications Example
      • ContentService Notifications Example
      • Creating And Publishing Notifications
      • Determining if an entity is new
      • MediaService Notifications Example
      • MemberService Notifications Example
      • Sending Allowed Children Notification
      • Umbraco Application Lifetime Notifications
      • EditorModel Notifications
        • Customizing the "Links" box
      • Hot vs. cold restarts
    • Inversion of Control / Dependency injection
    • Management
      • Using Umbraco services
        • Consent Service
        • Media Service
        • Relation Service
        • Content Service
        • Content Type Service
        • Localization Service
        • User Service
    • Plugins
      • Creating Resolvers
      • Finding types
    • Cache & Distributed Cache
      • Accessing the cache
      • ICacheRefresher
      • IServerMessenger
      • Getting/Adding/Updating/Inserting Into Cache
      • Examples
        • Working with caching
    • Response Caching
    • Security
      • API rate limiting
      • BackOfficeUserManager and Events
      • Cookies
      • Replacing the basic username/password check
      • External login providers
      • Locking of Users and password reset
      • Reset admin password
      • Umbraco Security Hardening
      • Umbraco Security Settings
      • Sensitive data
      • Sanitizing the Rich Text Editor
      • Setup Umbraco for a FIPS Compliant Server
      • HTTPS
      • Two-factor Authentication
      • Server-side file validation
    • Scheduling
    • Common Pitfalls & Anti-Patterns
    • API Documentation
    • Debugging with SourceLink
    • Language Variation
    • UmbracoMapper
    • Distributed Locks
    • Management API
      • Setup OAuth using Postman
    • Custom Swagger API
    • Umbraco Flavored Markdown
  • Tutorials
    • Overview
    • Creating a Basic Website
      • Getting Started
      • Document Types
      • Creating Your First Template
      • CSS and Images
      • Displaying the Document Type Properties
      • Creating a Master Template
      • Creating Pages and Using the Master Template
      • Setting the Navigation Menu
      • Articles and Article Items
      • Adding Language Variants
      • Conclusions
    • Creating your First Extension
    • Creating a Custom Dashboard
      • Adding localization to the dashboard
      • Adding functionality to the Dashboard
      • Using Umbraco UI library in the Dashboard
    • Creating a Property Editor
      • Adding configuration to a Property Editor
      • Integrating context with a Property Editor
      • Custom value conversion for rendering
      • Adding server-side validation
        • Default Property Editor Schema aliases
    • Creating a Multilingual Site
    • Add Google Authentication (Users)
    • Add Microsoft Entra ID authentication (Members)
    • Creating Custom Database Tables with Entity Framework
    • The Starter Kit
      • Lessons
        • Customize the Starter Kit
        • Add a Blog Post Publication Date
          • Add a Blog Post Publication Date
          • Add a Blog Post Publication Date
        • Add Open Graph
          • Add Open Graph - Step 1
          • Add Open Graph - Step 2
          • Add Open Graph - Step 3
          • Add Open Graph - Step 4
          • Add Open Graph - Summary
        • Ask For Help and Join the Community
    • Editor's Manual
      • Getting Started
        • Logging In and Out
        • Umbraco Interface
        • Creating, Saving and Publishing Content Options
        • Finding Content
        • Editing Existing Content
        • Sorting Pages
        • Moving a Page
        • Copying a Page
        • Deleting and Restoring Pages
      • Working with Rich Text Editor
      • Version Management
        • Comparing Versions
        • Rollback to a Previous Version
      • Media Management
        • Working with Folders
        • Working with Media Types
        • Cropping Images
      • Tips & Tricks
        • Refreshing the Tree View
        • Audit Trail
        • Notifications
        • Preview Pane Responsive View
        • Session Timeout
    • Multisite Setup
    • Member Registration and Login
    • Custom Views for Block List
    • Connecting Umbraco Forms and Zapier
    • Creating an XML Sitemap
    • Implement Custom Error Pages
    • Create a custom maintenance page
    • Creating a backoffice API
      • Documenting your controllers
      • Adding a custom Swagger document
      • Versioning your API
      • Polymorphic output in the Management API
      • Umbraco schema and operation IDs
      • Access policies
Powered by GitBook
On this page
  • Usage of Singletons and Statics
  • Example of using base class properties gotten through DI
  • Static references to scoped instances such as UmbracoHelper
  • Example 1
  • Querying with Descendants using DescendantsOrSelf
  • Too much querying (Over querying)
  • Using the Services layer in your views
  • Using Umbraco content items for volatile data
  • Processing during startup
  • Rebuilding indexes
  • Performing lookups and logic in Examine events
  • RenderTemplateAsync
  • Do not put logic inside your constructors
  • Do not eager load data, lazy load it instead
  • Not caching expensive lookups
  • Be mindful about memory
  • Best practices when using Models Builder
Edit on GitHub
Export as PDF
  1. Reference

Common Pitfalls & Anti-Patterns

Information on common Pitfalls and Anti-Patterns in Umbraco

PreviousSchedulingNextAPI Documentation

Last updated 7 months ago

This section highlights common pitfalls that developers often encounter. Some of the anti-patterns discussed here can lead to memory leaks, instability, or poor performance on your site. Be sure to read this section—it could save your site.

Usage of Singletons and Statics

Generally speaking, if you are writing software these days you should be using Dependency Injection (DI) principles. If you do this, you probably are not using or , and for the most part you should not be.

Since Umbraco comes with dependency injection out of the box, there really is not any reason to use singletons or statics. It makes your code difficult to test and hard to manage. Furthermore, the APIs become leaky and you will end up with more problems than when you started.

Dependency injection is available everywhere, and you can register your own services as well. Additionally, some resources are available through properties on certain base classes. For example, all Razor views that Umbraco creates expose an UmbracoHelper property you can access through @Umbraco. The other base classes that expose some things you might need like UmbracoContext are things like SurfaceController. Even here the services are initially gotten through DI, and you can inject further Umbraco and custom services that you might need.

For more information about consuming and registering your own dependencies have a look at the documentation.

Example of using base class properties gotten through DI

public class ContactFormSurfaceController : SurfaceController
{
    // The services are injected with DI and passed to the parent class
    public ContactFormSurfaceController(
        IUmbracoContextAccessor umbracoContextAccessor,
        IUmbracoDatabaseFactory databaseFactory,
        ServiceContext services,
        AppCaches appCaches,
        IProfilingLogger profilingLogger,
        IPublishedUrlProvider publishedUrlProvider)
        : base(umbracoContextAccessor, databaseFactory, services, appCaches, profilingLogger, publishedUrlProvider)
    {
    }

    [HttpPost]
    public IActionResult SubmitForm(ContactFormModel model)
    {
        // All normal form processing logic is left out of this example for brevity
        // You can access all of these because they are properties of the base class, 
        // if you need something else you can inject it in the constructor.
        
        //Profiling logger
        using (ProfilingLogger.TraceDuration<ContactFormSurfaceController>("Start", "stop"))
        {
            // UmbracoContext
            UmbracoContext.Content.GetById(1234);
        }

        return Ok();
    }
}

Static references to scoped instances such as UmbracoHelper

Example 1

public class BadApiController : Controller
{
    // Note that this is static, that's bad
    private static UmbracoHelper _umbracoHelper;
    
    public BadApiController(IUmbracoHelperAccessor umbracoHelperAccessor)
    {
        // Don't do this, this is bad
        if (_umbracoHelper is null)
        {
            umbracoHelperAccessor.TryGetUmbracoHelper(out UmbracoHelper umbracoHelper);
            _umbracoHelper = umbracoHelper;
        }
    }
}

This practice can cause memory leaks along with inconsistent data results when using this _umbracoHelper instance.

It is important to understand the difference between an object that has a Request-based scope and an object that has a Singleton/Application-based.

  • Application scope: If an object has a singleton/application scope, that means that this single object instance will exist for the lifetime of the application. The single instance will be shared by every thread that accesses it. Static variables will always be application lifespan.

  • Request scope: The web world is made up of requests and each request has its own thread. When an object is in the scope of a Request it only survives as long as the web request survives. At the end of the web request, it may either be disposed of or cleared from memory by the garbage collector. Request scoped object instances are not accessed by every other thread in the application unless you do something like the above.

An example of a request-scoped instance is the HttpContext. This object exists for a single request and it cannot be shared between other threads. Especially not other request threads. This is because it is where the security information for a given user is stored. The UmbracoContext is also a request-scoped object. In fact, it relies directly on an instance of HttpContext. The UmbracoHelper is request-scoped as well.

In the example above, the UmbracoHelper which has a request-scoped lifetime, will be statically assigned to a variable. It means that this particular request-scoped object is now bound to an Application-scope lifetime and will never go away. This could mean that under certain circumstances an entire Umbraco cache copy is stuck in memory. It could also mean that the Security property of the context will be accessed by multiple threads. However, this now contains the security information for a user from another request.

Additionally there is never really any reason to use static references. Instead, you should always inject your required resources, and let the DI container handle the lifetimes of the objects.

Querying with Descendants using DescendantsOrSelf

When using queries like this, you need to understand the implications. Here is a particularly bad scenario:

You have 10,000 content items in your tree and your tree structure is something like this:

- Root
-- Home
-- Blog (Collection with 9495 nodes)
-- Office Locations (Collection with 500 nodes)
-- About Us
-- Contact Us

You create a menu on your Home page like:

<ul>
 <li><a href="@Model.Root().Url()">@Model.Root().Name</a></li>
 @foreach (var node in Model.Root().DescendantsOrSelf().Where(x => x.Level == 2))
 {
  <li><a href="@node.Url()">@node.Name</a></li>
 }
</ul>

The query above renders out: Root, Home, Blog, Office Locations, About Us, Contact Us

This is going to iterate over every single node in Umbraco, all 10,000 of them. This will have a negative effect on the sites general performance.

Instead of using the snippet above, something similar to the sample below can be used:

<ul>
 <li><a href="@Model.Root().Url()">@Model.Root().Name</a></li>
 @foreach (var node in Model.Root().Children)
 {
  <li><a href="@node.Url()">@node.Name</a></li>
 }
</ul>

In many cases, you might know that there is only ever going to be a small number of Descendants. If so using Descendants or DescendantsOrSelf will not have a negative affect on the sites performance. It is important to always be aware of the implications of what you are writing.

Too much querying (Over querying)

Querying and traversing content is not free. Anytime you make a query or resolve a property value there is overhead involved. Think about every query you make as an SQL call: Too many requests can have a negative effect on the sites performance.

Here is a common pitfall in relation to this.

Following the example above, the menu is going to be rendered using the current page's root node:

<ul>
 <li><a href="@Model.Root().Url()">@Model.Root().Name</a></li>
 @foreach (var node in Model.Root().Children)
 {
  <li><a href="@node.Url()">@node.Name</a></li>
 }
</ul>

The @Model.Root() syntax is shorthand for doing this: Model.AncestorOrSelf(1). This means that it is going to traverse up the tree until it reaches an ancestor node with a level of one. As mentioned above, traversing costs resources and in this example, there are 3x traversals being done for the same value.

Consider writing something similar to the example below:

@{
 var root = Model.Root();
}
<ul>
 <li><a href="@root.Url()">@root.Name</a></li>
 @foreach (var node in root.Children)
 {
  <li><a href="@node.Url()">@node.Name</a></li>
 }
</ul>

Using the Services layer in your views

The Services layer of Umbraco is for manipulating the business logic of Umbraco directly to/from the database. None of these methods should be used within your views and can have a negative impact on the performance and stability of your application.

Your views should rely only on the read-only data services such as UmbracoHelper, ITagQuery and IMemberManager and the properties and methods they expose. This ensures that the data being queried comes from the cache and that you are not inadvertently making database changes.

For example, when retrieving a content item in your views:

@using Umbraco.Cms.Core.Services
@inject IContentService _contentService

@{
 // Services access in your views :(
 var dontDoThis = _contentService.GetById(1234);
 
 // Content cache access in your views
 var doThis = Umbraco.Content(1234);
}

If you are using services in your views, you should figure out why this is being done and, in most cases, remove this logic.

Using Umbraco content items for volatile data

This is one of the anti-patterns that could have the highest negative impact on your sites performance.

Umbraco content should not be used for volatile data. The Umbraco APIs and the way Umbraco data is persisted was not designed for this. When you need to store, write or track data that changes a lot use a custom database table or another service. Do not use Umbraco content nodes for this.

Some examples of what not to do, and what to do instead:

What not to do
Alternative

Hit counters to track the number of times your page has been viewed.

Use something like Google Analytics or a custom database table instead.

Creating new nodes for form submissions.

This should be stored in a custom database table.

Importing lots of data into Umbraco content nodes.

Import the data into custom database tables instead.

Processing during startup

Umbraco allows you to run some initialization code during startup by using UmbracoApplicationStartingNotification. Depending on what code is run, it can have an impact on the application startup. This is especially true for Package developer as your code could end up impacting many websites.

  • Putting logic in a property getter with a lock and setting a flag when it is processed.

  • Putting logic in a method with a lock and setting a flag when it is processed

The list above is not a complete list of options, as there are many different ways of achieving this.

It is important to ensure that the initialization logic executes only once for the lifetime of the application even when your app domain is restarted. If your initialization logic creates a database table that should only be executed one time, set a persistence flag. A persistence flag will indicate to your own logic that the initialization code has already been executed and does not need to be done again.

Rebuilding indexes

Rebuilding examine indexes can have a negative effect of the sites performance and is not a recommended practice. It is recommeded to ensure you are running the latest Umbraco and Examine versions if you are having trouble with out-of-sync index data.

The primary reasons your data will become out of sync are:

  • Old version of Umbraco.

  • Rebuilding indexes and restarting your app domain at the same time.

It is not recommended to rebuild your indexes unless you absolutely need to. If you need to do this often then it is advised to determine why and to try to resolve the underlying problem.

Performing lookups and logic in Examine events

There is a couple of well known Examine events: TransformingIndexValues and DocumentWriting. Both of these events allow the developer to modify the data that is going into the Lucene index. Many times we see developers performing service lookups in these methods. For example, using IContentService.GetById(e.NodeId) inside of these events could cause an N + 1 problem. This is because these events are executed for every single document being indexed. If you are rebuilding an index, this will mean that this logic will fire for every single document and media item going into each index. That could mean a large number of lookups and impact the site performance negatively.

Similarly, when executing logic in these events that perform poorly, then anytime you save or publish content or media it will slow that process down. And if you rebuild an index then any slow code running in these events will cause the indexing to go even slower.

RenderTemplateAsync

The API method is called RenderTemplateAsync allows you to be able to render a particular content item's template and get a IHtmlEncodedString in response. This could be useful if you want to send an email based on a content item and its template. However, you must be careful not to use this for purposes it is not meant to be used for.

Do not use this method for rendering content as this could cause severe performance problems if abused. For normal content rendering of module type data from another content item, you should use Partial Views instead.

Do not put logic inside your constructors

Constructors should generally not perform any logic. They should set parameter values, perform null checks and perhaps validate data.

There are a few reasons why this can become a performance problem:

  • The consumer of an API does not expect that by creating an object they should be worried about performance.

  • Creating an object can inadvertently happen many times, especially when using Language Integrated Query (LINQ).

Here is an example of how this can go wrong.

Your tree structure is something like this:

- Root
-- Home
--- Recipes (node id = 3251, Collection with 5000 nodes)
--- About Us
--- Contact Us

You have a custom model that looks like this:

public class RecipeModel : PublishedContentWrapped
{
    public RecipeModel(IPublishedContent content, IPublishedValueFallback publishedValueFallback) : base(content, publishedValueFallback)
    {
        RelatedRecipes = content
            .Parent
            .Children<RecipeModel>()
            .Where(x => x.Value<IEnumerable<int>>("related")
                .Contains(content.Id));

        Votes = content.Value<int>("votes");
    }
    
    public int Votes { get; private set; }
    
    public IEnumerable<RecipeModel> RelatedRecipes { get; private set; }
}
}

You run the following code to show the favorites:

@var recipeNode = Umbraco.TypedContent(3251);
@{
 var recipeNode = Umbraco.Content(1234);
}

<ul>
 @foreach (var recipe in recipeNode.Children
  .Select(x => new RecipeModel(x, _publishedValueFallback))
  .OrderByDescending(x => x.Votes)
  .Take(10))
 {
  <li><a href="@recipe.Url()">@recipe.Name</a></li>
 } 
</ul>

To show the top 10 voted recipes's this will end up doing the following:

  • It will iterate over all 5000 Recipes.

  • It will create and allocate 5000 instances of RecipeModel.

  • For each RecipeModel created, it will traverse upwards, iterate all 5000 recipes then resolve property data for 2 properties.

This means that there is now an additional 5,000 new objects created and allocated in memory. The number of traversals/visits to each of these objects is now 5000 x 5000 = 25,000,000.

The other problem is that the logic used to lookup related recipes is inefficient. Instead, each recipe should have a picker to choose its related recipe's and then each of those can be looked up by their ID.

Do not eager load data, lazy load it instead

The above example could be rewritten like this:

    public class RecipeModel : PublishedContentWrapped
    {
        public RecipeModel(IPublishedContent content, IPublishedValueFallback publishedValueFallback) : base(content, publishedValueFallback)
        {}

        private int? _votes;
        public int Votes
        {
            get
            {
                // Lazy load the property value and ensure it's not re-resolved once it's loaded
                return _votes ??= this.Value<int>("votes");
            }
        }

        // Just return the Ids, they can be resolved to IPublishedContent instances in the view or elsewhere,
        // doesn't need to be in the model - this would also be bad if the model was cached since all of the
        // related entities would end up in the cache too.
        private List<int> _related;

        public IEnumerable<int> RelatedRecipes => _related ??= this.Value<IEnumerable<int>>("related").ToList();
    }

The code will still iterate over all Recipes meaning that the number of traversals/visits to each of these objects will be 5000.

There really is not much reason to create a RecipeModel. Instead it could be written like:

@{
 var recipeNode = Umbraco.Content(1234);
}

<ul>
 @foreach (var recipe in recipeNode.Children
  .OrderByDescending(x => x.Value<int>("votes"))
  .Take(10))
 {
  <li><a href="@recipe.Url()">@recipe.Name</a></li>
 }
</ul>

Not caching expensive lookups

Based on the above 2 points, you can see that iterating content with the traversal APIs ends up being expensive in terms of performance.

How to solve performance issues, will always depend on the specific scenario. One thing to consider is to cache the IDs of the content you need in your critical code. Then you could retrieve it from the cache by ID.

When you need to render the same four pieces of content for your navigation, then cache, or hardcode, the IDs of those content items. Then you can retrieve them with the ID using Umbraco.Content. This will always be faster than trying to traverse your content tree and finding the content programmatically. It will do a direct lookup in the cache, meaning that your code does not have to do many traversals to get your content.

Be mindful about memory

When memory is used, for instance creating 5,000 recipe models with a Select statement, Garbage Collection needs to occur. This turnover can cause performance problems. The more objects created, the more items allocated in memory, the harder the job is for the Garbage Collector == more performance problems.

Even worse is when you allocate a lot of or large items in memory. They will remain in memory for a long time ending up in "Generation 3" which the GC tries to ignore for as long as possible. It does so because it knows it is going to take a lot of resources to clean up.

Best practices when using Models Builder

In many cases, . Instead of initialization everything you need as soon as the application starts you could execute your initialization code only when it is required. This can be achieved in different ways:

Using and put the initialization logic in its callback.

Using .

Extending models should be used to add stateless, local features to models. It should not be used to transform content models into view models or manage trees of content. You can read more about this in the

Singletons
Statics
Dependency Injection
initialization code can be done lazily instead of eagerly
Lazy<T>
LazyInitializer
Understanding and Extending Models Builder documentation