Try Now
More in this section
Blogs RSS feed

How Load-balancing Was Improved in Sitefinity 9.2

by Peter Filipov

In a load-balancing scenario all instances of an application must have the same configurations across the nodes, and when a new version comes it should update the nodes one at a time and avoid down time.

There are two types of configuration settings in the CMS. The first ones are related to settings which need to be changed for each environment. The change of these values is handled by the developers and automated with the help of config transformations. The second type of settings are applications settings, which are changed during runtime.

Here is a table comparing both types:

Environment configurations

Application configurations

Related to system setup

Related to applications runtime functionality

No need to change runtime

Need to be modified runtime

Must have different values on different environments:

development, staging, live

No need to change on different environments

Should not be stored in the database

Should be stored in the database

Managed by developers

Managed by users


Prior to version 9.2 of Sitefinity, the system saved all its configurations settings in either the config files on the file system or in the Database (but not both).

When the configurations’ behavior and both storage modes are combined in terms of load-balancing they bring three complex scenarios.

The first one is when all of the settings are saved on the file system and they are changed during the execution of the web application. The problem is that Sitefinity is prevented from operating in a load-balanced scenario because each instance had its own config files and with time configurations between different nodes became inconsistent.

The next case is where all of the nodes are using shared config files in order to avoid the problem from case one. But this brings availability and concurrency issues during deployment to live servers.

Because of the above two cases the engineering team introduced the ability to save all of the configurations into the Database. This allows safe runtime modification of the configurations when a load-balancer is used. But it also breaks the continuous delivery process since there is no way for a developer to push environment configuration changes with the source control. The developer has to manually apply these changes on the relevant environment Database, since no Database changes are pushed to other environments from Dev. Managing other environments and the delivery process should be completely automated and not part of the developer's responsibilities. This scenario severely compromises the continuous delivery process.

The conclusion from the cases is that we need to have a mixed solution.

The Configuration Panacea with Sitefinity 9.2

The new storage mode in Sitefinity makes the complexity of Load Balancing setup easy to manage. With the latest version of the CMS this mode is on by default requiring no action on your part.

With Sitefinity 9.2 a new config storage mode is introduced—Auto. It allows some Sitefinity configuration sections to be saved in the Database and others on the file system. As a result, this allows easier setup of Sitefinity for continuous delivery in a load-balanced environment by choosing which configurations are to be saved in the database and which are to remain on the file system. Configurations that are identified as environment configurations should be saved on the file system and those identified as application configurations should remain in the database.

The separation of the settings is totally automated and handled by the CMS, and we shouldn’t need to do anything else. If we want to put some application settings into the file configs we could with the help of FileSystemModeRegion, which explicitly saves the entire section on the file system. E.g.:

using (new FileSystemModeRegion()) { ConfigManager.GetManager().SaveSection(myConfigSection); } Or ConfigManager.GetManager().SaveSection(ConfigSection section, bool saveInFileSystemMode)

If these sections also contain settings that need to be modified during runtime by the system, they should be refactored and moved to the database. This is only required for Sitefinity to work consistently in a load-balanced scenario as stated earlier.


To use Sitefinity in a load-balancing environment without any additional and quirky configurations, just use the newly introduced mode of the storage configuration property—Auto.

Leave a comment