🚀 Welcome to MDriven Learn –  MDriven is now on Discord!  Don’t miss the latest Release Notes.
Memory optimization
This page was created by Stephanie on 2023-05-26. Last edited by Wikiadmin on 2026-07-29.

You can reduce and diagnose memory use in long-running MDriven Turnkey and MDrivenServer installations by using the built-in cleanup behavior, limiting inactive streaming clients, and—only for the stated .NET Framework/IIS scenario—reviewing garbage-collector settings.

What MDriven manages automatically

MDriven includes memory-management behavior that runs without configuration. This behavior is especially relevant when one server process serves many users over time.

Mechanism What it does Example
Shared large values Large database-loaded byte[] and string values can be shared between EcoSpaces in the same server process instead of retaining one copy per user. If many users view the same stored image or long text, the server can retain one shared value rather than a separate value for every active EcoSpace.
Pruning MDriven periodically deallocates unused data structures, including structures in views and in EcoSpaces belonging to active users. A user keeps a streaming application open all day but stops using a part of the application. Periodic pruning can release data and internal structures that are no longer in use.
ViewModel cleanup ViewModels that have not been used for a few minutes are removed. A ViewModel opened during an earlier interaction is not kept indefinitely when it is no longer used.
Subscription and publisher cleanup MDriven periodically removes subscriptions and change publishers within EcoSpaces. A long-running session that has accumulated change-notification infrastructure can be pruned rather than growing without limit.

Pruning is MDriven-aware cleanup. It releases data and framework structures that are no longer needed; the .NET garbage collector can subsequently reclaim objects that are no longer referenced. This is different from relying on .NET garbage collection alone, because MDriven must first identify model-aware structures, such as subscriptions, publishers, derived data, and view-related data, that can be released.

Share large stored values

SharedBigValue is enabled by default. It applies when a value loaded from persistence meets all of these conditions:

  • The attribute value is a byte[] or string.
  • The value is larger than 8192 bytes.
  • The value is the latest version (maxint version).
  • The object ID, attribute ID, and typesystem checksum match.

The feature targets database-loaded values. Updates to large values continue to be handled normally. Shared values are not actively destroyed when a new model is uploaded; that scenario is expected to be uncommon because the changed checksum causes existing EcoSpaces to be recreated.

For a practical verification, create a model with image and text attributes, open it in two browsers, and update a large text or image value in one browser. Confirm that the other browser receives the update. See Documentation:SharedBigValue for implementation details and the setting that disables the effect for troubleshooting.

Control how long inactive Turnkey clients retain server memory

A running Turnkey streaming application retains an active memory space for each connected client. By default, no client timeout is active, so an inactive connected client can continue to retain server resources.

Use Documentation:Turnkey Client Timeout when users can be moved after inactivity to an MVC timeout page that does not require Turnkey server resources.

  1. Decide whether the timeout applies to every page or only selected pages.
  2. For a server-wide timeout, add <TurnkeyTimeoutMinutes>1</TurnkeyTimeoutMinutes> to TurnkeySettings.xml. Replace 1 with the number of minutes appropriate for your application.
  3. For a page-specific timeout, set the TurnkeyTimeoutMinutes tagged value on that ViewModel. The ViewModel setting takes precedence over the server-wide setting.
  4. If users need a branded timeout page, create a ViewModel named Timedout. It must be an MVC page.

A timeout is not a substitute for pruning. Pruning reduces unused structures within active EcoSpaces; a timeout can end the server-side streaming presence for an inactive client. See Documentation:Turnkey Client Timeout and Documentation:Span.TurnkeyTimeoutMinutes.

Inspect memory before changing settings

Use Serverinfo to inspect application status and memory information before and after an operational change.

  1. In the Turnkey portal, enable Show Debug Info for the site.
  2. Open https://<yourSite>/Developer/Serverinfo.
  3. Record the relevant application and memory information.
  4. Change one variable at a time—for example, a Turnkey timeout value—and allow representative user activity.
  5. Recheck Serverinfo and the application logs to compare the result.

Serverinfo also exposes temporary controls for adjusting stale-application pruning times and pruning intervals. These controls are intended to shorten observation cycles while you evaluate settings; use them to test behavior without waiting for normal long intervals. For logging locations and access requirements, see Documentation:Serverinfo.

.NET Framework garbage-collector settings on IIS

The settings in this section apply only to the .NET Framework scenario stated here: .NET Framework versions before 4.8.1 running on IIS. They do not apply to .NET Core.

By default, an MDriven server uses the Server garbage-collector (GC) mode with the Interactive setting. The GC runs in the background to reduce short user-visible pauses. GC tuning is a trade-off:

Goal Effect described by the setting guidance
Favor CPU performance Collect less frequently, which can increase memory consumption.
Favor lower memory consumption Collect more frequently so unused memory can be released sooner, which can increase CPU work.

For a Windows machine that hosts more than one Turnkey or MDrivenServer instance, the following runtime settings are recommended in the source guidance to reduce per-site working-set consumption.

  1. Open aspnet.config in C:\Windows\Microsoft.NET\Framework64\v4.0.30319.
  2. Locate its <runtime> section.
  3. Add the following elements within that section:
<runtime>
  <performanceScenario value="HighDensityWebHosting"/>
  <gcTrimCommitOnLowMemory enabled="true"/>
</runtime>

performanceScenario configures GC for high-density web hosting. gcTrimCommitOnLowMemory trims committed memory when the server is under low-memory conditions. Review the impact on both memory consumption and CPU use after deployment.

Do not use this section as .NET Core configuration guidance. For .NET Core GC configuration, use the Microsoft .NET runtime documentation linked below.

Reduce startup memory as well

ModlrLeanLoad is enabled by default in builds after 2023-09-05. It creates reduced model files in the application's App_Data directory so that an unchanged model can start without loading assets and most diagram and ViewModel content into the startup model. This reduces startup time and memory pressure; it is complementary to runtime pruning.

If you need to force regeneration on the next start, delete ModlrLeanLoadChecksum.xml. See Documentation:ModlrLeanLoad for the generated files, checksum behavior, and Softview-related limitations.

Design and code choices that affect memory

Memory optimization starts with what an application loads. In model expressions, use OCL where it belongs—in constraints, derived attributes, associations, ViewModels, and actions. In C# code, prefer LINQ through persistence storage queries when querying persisted objects rather than manually fetching objects one at a time. This lets the engine understand the intended result and use lazy fetch in appropriately sized chunks. See Documentation:A few words on linq for examples and limitations.

If your application reports missing Microsoft.IO.RecyclableMemoryStream or System.Buffers, follow Documentation:RecyclableMemoryStream to add the named NuGet packages. Those assemblies are used to minimize memory pressure.

See also

Memory optimization

MDriven includes built-in memory optimization that does not require configuration.

Built-in memory management

Large blobs in a model are held in a shared location for all clients. MDriven also periodically performs the following cleanup, usually every few minutes:

  • Prunes unused data structures, including in views and in EcoSpaces of active users.
  • Removes ViewModels that have not been used for a few minutes.
  • Removes subscriptions and change publishers within EcoSpaces.

Adjust pruning while testing

Use the ServerInfo page to temporarily adjust the time before stale applications are pruned and the server pruning interval. These settings are intended to help you test other changes without waiting for normal pruning periods.

.NET Framework hosting memory settings

For MDriven Server on .NET Framework versions earlier than 4.8.1, excluding .NET Core on IIS, MDriven Server uses Server GC mode with the Interactive setting by default. This configuration is intended to run garbage collection in the background while minimizing short user delays. Garbage-collection tuning involves a trade-off among user experience, memory use, and CPU use.

For lower working-set memory per site in high-density Windows hosting, the documentation describes adding the following settings to the `runtime` section of `aspnet.config` at `C:\Windows\Microsoft.NET\Framework64\v4.0.30319`:

<performanceScenario value="HighDensityWebHosting"/>
<gcTrimCommitOnLowMemory enabled="true"/>

The documentation recommends both settings when more than one Turnkey or MDriven Server instance runs on the same Windows machine.

Checklist

Area Check
Built-in cleanup Confirm that the expected periodic pruning of unused data structures, unused ViewModels, subscriptions, and change publishers is appropriate for the environment.
Testing Use ServerInfo temporary pruning settings to shorten observation cycles while evaluating changes.
Shared Windows hosting If multiple Turnkey or MDriven Server instances run on one Windows machine, assess the documented .NET Framework GC settings under the stated runtime conditions.

See also