Optimizing performance of MVC sites

The performance of your website depends on many factors:

  • The total number and content tree organization of pages
  • The amount of custom client scripts and their efficiency
  • Custom functionality added to the application or individual sites
  • The hardware and environment on which the site and database server are running
  • The available resources if the server is shared with other applications

Tip: Finding sources of performance problems

Check the system's event log for errors.

This page contains recommendations that can help you optimize the performance of MVC sites built with Xperience.

On this page

Optimizing on-line marketing performance

For high-traffic websites that use the Xperience Enterprise on-line marketing functionality, we strongly recommend following the Best practices for on-line marketing performance in addition to the general recommendations listed below.

Loading data efficiently

Transferring data between storage spaces and the application can be one of the main performance bottlenecks. When retrieving content from the Xperience database (or other external sources), load only the data that you require in your views or other related code. In most cases, you do not need all data columns available in the source. The less data you retrieve, the faster your pages will be.

When loading data using the DocumentQuery or ObjectQuery API (for example in custom repositories and services), you can limit which data columns are loaded through the Columns method – specify the names of the required columns as an array of strings.

Example
// Gets article data using a generated provider
IEnumerable<Article> articles = ArticleProvider.GetArticles()
	.Columns("NodeID", "NodeAlias", "NodeSiteID", "ArticleTitle", "ArticleText") // Limits the retrieved data columns
    .OnSite("MySite")
    .Culture("en-US")
    .Path("/Articles/", PathTypeEnum.Children)
	.ToList();

Tip: In custom repositories or services, you may often need to wrap and extend DocumentQuery or ObjectQuery calls from other classes or providers. In these scenarios, use the AddColumns method instead of Columns – this adds to the list of retrieved columns without overriding any columns specified by the previous call.

Caching data and page output

Whenever possible, use caching for retrieved data and the output of controller actions:

  • See Caching on MVC sites for more information.
  • To avoid displaying of outdated content, set up cache dependencies.
  • Use cache keys containing variables to cache different versions of dynamic content (for example different page output for each user).

Organize content in the most effective way

You can store your site's content either in Pages, Custom tables, Module classes or Media libraries. Each storage type is designed for a different type of data.

Pages provide many advantages and by far the best editing options for content. However, storing extremely large numbers of pages in the system can significantly affect the website's performance. Refer to Defining website content structure for more information. You can also reduce the amount of pages stored in the content tree by setting up archival for outdated pages.

Optimize how the system behaves when editing content

When creating and updating pages under a parent page that already has a very large amount of descendants in the administration interface, the Settings -> Content -> Content management -> New page order setting can significantly affect performance. If you encounter such problems, we recommend using the Last option, as it is the least performance demanding.

Enabling IIS content compression

IIS content compression allows the system to lower the volume of transferred data by compressing the resources. There are two types of compression available in the IIS:

  • Dynamic compression – compression of dynamically generated responses
  • Static compression – compression of static content (images, document and other files on the file system)

To enable IIS compression in your MVC project:

  1. Install the required compression modules.
  2. Add a urlCompression element into the projects Web.config file and specify the following settings:
    • doDynamicCompression – enables or disables the dynamic compression of content. The default value is true.
    • doStaticCompression – enables or disables the static compression of content. The default value is true.

dynamicCompressionBeforeCache incompatible with Xperience

Using the dynamicCompressionBeforeCache attribute of the urlCompression element is not possible in the Xperience environment.

Xperience uses a custom HTTP module, which modifies the HTML output with output filters (resolves relative links, adds anti-forgery tokens). When using the dynamicCompressionBeforeCache setting, HTML output is compressed before any output filters are applied and this results in invalid HTML output.

Precompilation

Consider precompilation of the entire project before deploying to the production environment. Precompilation can significantly improve the first-load response time of your website.

Scaling out MVC sites

If your site's performance is not satisfactory after you have taken all possible steps to optimize the website's code, you can consider scaling your hosting environment to multiple web farm servers.

Your MVC application and administration application should already be configured to run as servers in an automatic web farm (see Starting with MVC development). The web farm ensures that the MVC application invalidates cache according to content or setting changes made in the administration application and vice versa.

Licensing of the web farm servers works automatically for basic scenarios – see Licensing for Xperience applications for details.

If you wish to use a web farm to scale the site's performance, you can add further instances of the MVC application. We recommend using the following process:

  1. Develop and test the site in a web farm with two servers (one MVC application, one administration application).
  2. Deploy any number of additional instances of the same MVC application. Each instance must connect to the same Xperience database.

The automatic web farm mode automatically registers the new instances as web farm servers and ensures correct synchronization (among all instances of the MVC application and the Xperience administration application). One way to create a scalable website is to deploy your instance to cloud hosting.

If you need to scale the performance of the administration interface used to manage the site content and settings, you can also run multiple instances of the administration application in the web farm. In this scenario, you need to use one of the servers as the "primary" Xperience instance (for example for holding files shared by the entire web farm, such as locally stored search indexes).

Note: If you scale out to have more than the two basic web farm servers per MVC site (live site + administration), you need to have a license that supports the additional number of web farm servers.


Was this page helpful?