Best practices for EMS performance in MVC
Running the Kentico EMS on-line marketing functionality typically increases the performance requirements for websites with very heavy traffic. This page provides best practices for optimizing the performance of websites deployed within the MVC development model.
When trying to scale your MVC application, the following recommendations generally apply:
- To increase the supported traffic load (requests per second, new contacts per second, concurrent visitors), deploy additional instances of your MVC live site application (as web farm servers).
- To increase the supported volume of on-line marketing data, increase the size and performance of the database server.
Performance best practices
To achieve optimal performance with Kentico EMS websites, follow the recommendations in the sections below.
Note: In addition to the instructions listed on this page, also follow the general performance best practices for all types of websites: Optimizing performance of MVC sites
- Optimize your web farm environment
- Separate the on-line marketing database
- Set up the SQL server
- Optimize database indexes
- Optimize send out of marketing emails
- Set up automatic deleting of contacts
- Disable event logging for automation and marketing emails
- Optimize scoring and contact group recalculation
Optimize your web farm environment
The Kentico MVC development model already uses web farms for synchronization of cached content and of most files. To handle high traffic loads, you may need to increase the number of servers in the web farm. To see how to properly set up the web farm synchronization in Kentico, see Configuring web farm servers.
When logging activities from MVC applications, the API does not ensure recalculation of contact scores, contact groups, personas and marketing automation triggers. For performance reasons, these recalculations are performed by the Kentico application.
Important
Because the Kentico application itself does not usually receive traffic from site visitors, you need to keep the application alive. For example, you can set the Start Mode advanced setting of the used application pool in IIS to AlwaysRunning.
By default, the system batch processes activities and contact detail updates every 10 seconds. You can configure the processing interval separately for the Kentico and MVC application. Adding the below key to the MVC application affects the interval at which logged activities and contact detail updates are saved from the memory into the database. Adding the below key to the Kentico application affects how often Kentico recalculates the data that could be affected by activities and contact updates.
If your system processes a large number of activities and contact updates, you may need to increase the default interval.
Open your project’s web.config file.
Add the following key into the appSettings section of the file. Increase the value to reflect how often you want the activities and contact updates to be processed.
Processing activities and contact updates every 30 seconds<add key="CMSProcessContactActionsInterval" value="30" />
Save the file.
The system now processes activities and contact detail updates in accordance with the configured intervals.
Separate the on-line marketing database
Running the on-line marketing features on a high-traffic website places a significant load on the database server. To distribute the load of Kentico’s standard and on-line marketing functionality, separate your on-line marketing database to a second database server.
Set up the SQL server
If you have the option to administer the website’s database server, we recommend that you perform the following steps:
Optimize the database’s Log and Data files:
- Set a large initial size for the data file and disable Autogrowth
- Store the log and data files on different drives
- Store the SQL server error log files on the same drive as the main data file
- Store the server’s tempdb database to the same drive as the main data file
Enable the Lock Pages in Memory Option on the database server
Optimize database indexes
By default, the Kentico database tables have indexes optimized for the most common scenarios. However, each EMS website uses a different set of on-line marketing features, with different visitor behavior, and a unique distribution of data.
For optimal performance, we recommend that you regularly use a tool (for example the Database Engine Tuning Advisor) to analyze your database performance. Consider the suggestions and implement any database index adjustments that are suitable for your specific project.
Additionally, the default database indexes are optimized for live site performance, not for operations in the Kentico administration interface. With extremely large volumes of data (millions of records), you may encounter slow performance or timeouts in object lists – for example, if you change the default list ordering or when filtering according to certain fields. You can address these problems by creating custom database indexes with the corresponding columns (note that this may have a negative impact on live site performance).
Optimizing Salesforce integration
The default Kentico indexes are optimized without considering the Salesforce integration. If you are using the Salesforce integration with a large number of contacts, we recommend that you optimize database operations by manually creating a database index with the following columns on the OM_Contact table:
- ContactSalesForceLeadID
- ContactSalesForceLeadReplicationDisabled
- ContactSalesForceLeadReplicationSuspensionDateTime
The index should be non-clustered and non-unique. See the Create Nonclustered Indexes article for more information.
Optimize send out of marketing emails
Optimize the number of macros in emails
Composing marketing emails for a large number of recipients can decrease the system’s performance, particularly if the emails contain macros and use other email marketing features. Approximately 5% of the email generation time is spent on Tracking clicked links, Tracking opened emails, and Logging on-line marketing activities, when these features are enabled. The time spent on resolving macros grows linearly with the number of macros used in the emails, however, this takes up only a small portion of the total email generation time. Note that the growth of the macro resolving time is linear only if all data is cached and no database operations are performed within the macros.
As a result, we recommend minimizing the number of macros in the content of your marketing emails to ensure a shorter email generation time.
EMS email generation performance tests
These recommendations were put together based on the results of several tests performed on Kentico EMS.
The marketing email send out was tested for performance in an environment with no real traffic, measuring only the generation of emails. The testing environment consisted of a web server and database server, without a separated on-line marketing database. The tested emails contained up to 50 data macros and up to 5 macros using recipient properties.
In addition to the information stated above, the results also show that the email generation time grows linearly with the number of email recipients.
Disable CSS inlining
Inlining of the CSS markup included in marketing email templates can have a negative influence on the performance of your system when composing emails. We recommend disabling CSS inlining to reduce the email generation time.
Enable the email queue
When generating a large amount of emails, we recommend configuring the system to use the email queue and setting the Network delivery method for your SMTP server. When using the Network delivery method with the email queue enabled, the system temporarily stores all outgoing emails in the database instead of sending them directly to the SMTP server.
Set up automatic deleting of contacts
The contact management features create contacts and log activities for every visitor, which generates a very large amount of data on high‑traffic websites. Extremely large numbers of stored contacts and activities may slow down certain operations in the system and be overwhelming for your marketers.
To reduce the volume of data, we recommend that you configure the system to regularly delete contacts that meet certain conditions and are no longer relevant.
Disable event logging for automation and marketing emails
To reduce system overhead on EMS instances with a very large number of contacts, we recommend that you disable event logging for the following actions:
- Transitions between steps of automation processes
- Sending of marketing emails (within email feeds)
Add the following keys to the appSettings section of the web.config file:
<add key="CMSLogMATransitions" value="false" />
<add key="CMSLogNewsletterIssueEvents" value="false" />
Optimize scoring and contact group recalculation
Recalculation of contact scores and contact groups can be a resource-intensive process that may reduce website performance.
- When scheduling score recalculations and contact group rebuilds, avoid your website’s peak traffic hours.
- If you use custom macro rules in your scoring rules or contact group conditions, implement translators to significantly improve recalculation performance.