Hide menu Last updated: Aug 21 2017
Area: Episerver DXC Service Applies to versions: Not applicable

Performance considerations

Below we describe some specific performance-related areas that are particularly important to consider for cloud-based solutions, compared to on-premise solutions.

CDN settings

The purpose with a content delivery network or content distribution network (CDN) is to ensure high availability when serving content to visitors. CDN consists of a globally distributed network of proxy servers deployed in multiple data centers. CDNs will deliver content from the fastest and closest server available.

The CDN servers are designed to cache content according to the cache rules you define in the HTTP headers from your application. It is critical that these caching rules are correctly set in order for your solution to scale properly. 

See CDN recommendations for more information.

Site startup

Proper site warmup is crucial for cloud-based environments. Since a node may be brought out for maintenance at any time, and then put back in during peak hours, a node that gets a full share of traffic without being warmed up first, will cause response time spikes and increasing risk of outages.

Use custom scripts, or the built-in ASP.NET feature that automatically starts up and initializes a web application, to warm up the server and getting data caches ready. See Initialization for more information.

Limiting the number of content types is a good practice. During a startup, all assemblies will be scanned and all views will be cached. A large number (200+) of content types significantly affects the startup time. It is also recommended to keep the Web App below 1 GB at all times. This includes binaries and .cshtml views, but not media assets and logs. These should be written to a BLOB storage container.

Output cache

Cloud-based solutions are more likely to scale out the web servers rather than to scale them up. This means that each front end node also contributes to a constant load to the database. In other words, if you go from two front-end servers (a typical on-premise setup) to four front end servers, while keeping the total throughput the same, the load on the database server increases.

When scaling out it is important to ensure that the machines that spend most effort building a page are the front-end servers. Caching in multiple layers (object caches, partial HTML caches such as for complex menus and/or full output cache), helps avoid a "cache stampede", especially when combined with warmup.

By default when a page is published, all output caches are immediately invalidated for all sites. This causes all output cached pages to be re-rendered using the lower-level caches. Most of these lower-level caches remain valid after a publish, except the caches for the page that was published. It is therefore important to ensure that proper multi-layer/partial caching is implemented for rendered pages with heavy data processing. See Caching for more information. 

Entity tags (ETags)

The ETag or entity tag is part of HTTP protocol, and is used to determine web cache validation. See   CDN recommendations for information on how to use ETags.


In a cloud environment, retry policies become increasingly important. Transient errors may occur due to network issues, or maintenance of infrastructure elements, and retry policies allow the application to gracefully recover from such errors without propagating the error to the end user.

Retry mechanisms for Azure services differ, as each service has different requirements and characteristics. Therefore each retry mechanism is tuned to a specific service. See information about transient faults and retry policies, and the Azure SDK for .NET for guidelines.


As the virtual machines hosting a Web App may be restarted at any time, this means that you risk losing any information stored in the file system. Additonally, if you have large media volumes it is recommended that assets are stored in a BLOB storage instead of in the Web App, as this will limit scalability. Episerver provides access to BLOB storage through a BlobProvider interface.

Note: Some third-party components such as Lucene.NET that use file shares or files local to the web server, may have problems with high traffic in a cloud environment, and are therefore not supported.

Related topics