Recommended environment settings
To achieve best results with Sitefinity CMS when the environment and its settings are concerned you should consider the following.
Run the application pool as a 64 bit process
When running Sitefinity CMS as a 32-bit process, by default, you have a limit of 2GB virtual memory space for your application. There are many factors determining the usage of this virtual space like the application load and custom implementations. Under continuous high load, some virtual space fragmentation may be observed. This can cause out of memory exceptions in the application, causing it to recycle before the physical memory of the application, which is actually committed, can reach or exceed the 2GB mark. This is why, we recommend running Sitefinity CMS in 64-bit mode when deploying high load applications.
Framework version .NET 4.5
There are a few optimizations that you can take advantage of when running your Sitefinity CMS application on .NET 4.5. The Multi-Core Just-In-Time compilation and the background garbage collections are valid for all scenarios. Other memory usage optimizations are useful only in high-density web hosting scenarios. High-density web hosting scenario is when you have a lot of less loaded applications and you want to optimize per-site resources consumption, like memory and space. This is usually the case with shared hosting providers.
Multi-Core Just-In-Time compilation for faster startup
Some of the benefits when running Sitefinity CMS under .NET 4.5 do not require any additional settings or tweaking. Such as the multi-Core Just-In-Time compilation optimization that reduces startup speed for ASP.NET applications. For more information, see Using multi-Core JIT compilation for faster startup.
This feature profiles your application on its first start keeping track of the startup methods that are executed and consequently which part of the managed assemblies must be compiled. Next time you start the application, the Just-In-Time compilation is being executed on a separate thread compiling the required methods ahead of their execution.
Background Garbage Collection
In .NET 4.5, the server default garbage collector mode for website applications introduces support for concurrent collections. It minimizes long blocking collections, while continuing to maintain high application throughput. This benefits heavy loaded applications a lot, because the full garbage collections (generation 2) do not block all threads for as long as the default .NET 4.0 GC server mode. For more information, see An Overview of Performance Improvements in .NET 4.5
Another thing to consider is that according to Microsoft some of the causes for Large Object Heap fragmentation have been fixed in the garbage collector implementation in .NET 4.5.
High density web hosting recommendations
Machine wide garbage collector setting
In .NET 4.5, a new machine wide setting is provided that minimizes application memory usage. Sitefinity CMS can use significantly less memory with this setting enabled (sacrificing performance). For more information, see Tuning garbage collection to optimize for memory.
Generally, this setting combines more detailed configurations, most of which were available in previous versions of .NET. For more information, see ASP.NET 2.0/3.5 Shared Hosting Configuration.
IMPORTANT: These settings are reducing memory consumption at the expense of performance. Consider them only if the memory usage of Sitefinity CMS is the limiting factor in achieving your goal.
Sharing Common Assemblies
When hosting multiple websites on the same server they often use common assemblies. However, each application has its own copy of those assemblies and once started they load them in their private memory. This can be avoided by sharing those assemblies between all applications that are using it. This technique is introduced in .NET 4.5 and is called assembly interning. It reduces the private memory consumption of every Sitefinity CMS applications by about 50MB. Those 50MB memory become shared memory that is shared across all Sitefinity CMS instances. Therefore, the performance gain of those free megabytes increases with the number of application instances hosted on a given machine.
For more information, see Sharing Common Assemblies
NOTE: The aspnet_intern.exe that is used to share the assemblies is part of Visual Studio 11 SDK but works as a standalone executable. Therefore, you do not need to install Visual Studio and Visual Studio SDK on your production server in order to use it.
For more information, see Tips for optimizing performance.