Scaling and configuring Content Delivery

Current version: 10.4

Content Delivery (CD) roles delivers your content to your visitors. You can configure multiple CD instances to meet your scaling requirements.

Installation

Use the Sitecore Installation Framework (SIF) or the Sitecore Azure Toolkit (SAT) to install the Content Delivery (CD) role. Refer to the installation guide for your version of the platform for more information.

Scaling the Content Delivery role

The following table describes your options for scaling the Content Delivery (CD) role:

Scaling option	Supported	Notes
Combined instance	No	The Content Delivery role must not be combined with any other role in production. The CD role can only be combined with other roles in the following circumstances: Combined Content Delivery, Content Management, and Processing - this topology is known as XP Single. Combined Content Delivery and Content Management in an “Experience Manager only” environment. This assumes that analytics is disabled, and that your topology does not include the Processing role. Note In a developer environment, all core roles can be combined into a single instance. This includes Content Management, Content Delivery, xDB Processing, and EXM Dispatch. This setup is not recommended in production.
Standalone instance	Yes	You can deploy Content Delivery as a standalone role. You can dedicate one or more Content Delivery instances to handle session expiration.
High availability and failover	Yes	You can fail over to a passive instance or set up multiple active instances behind a load balancer.
Horizontal scaling for load distribution	Yes	The CD role can be scaled horizontally into a load balanced content delivery cluster or across multiple data center to provide geographic scaling or data center level fail-over. In a scenario with multiple CD clusters, be aware of the following: Each cluster has its own dedicated Private Session State Store. Each cluster has its own dedicated Web database. Federated authentication is recommended. Replication of the Security database is not supported.
Clustering	Yes	You can set up multiple clusters of Content Delivery servers. Each cluster can have its own Web database. In 9.1 and later, Content Delivery does not require a connection to the Core database. Note If you want to use Sitecore's default user management to support extranet users, all Content Delivery instances must connect to a centrally located Security database.

Performance tuning tasks

To improve the performance of your CD role, consider the following performance tuning options:

Tune and configure caching.
Use one or more dedicated CD instances to handle session expiration. This is supported by the Redis provider in 9.1 and earlier. In Sitecore 9.2 and later, all session state providers support this feature.
Tune session expiration.
Tune session end batching.
Configure session cleanup. The default setting favors performance by deleting expired sessions from the session state database immediately.
Reduce the tracker's Reference Data Client API timeout. Reference Data service response time can affect CD response time.
High resource consumption by the Reference Data database may result in a slower response time from the Reference Data service and degrade Content Delivery performance. There is a patch available for Sitecore 9.0 - 9.2.
Reduce the tracker's xConnect Client API timeout. The xConnect Collection service response time can affect the CD response time. If you use the xConnect Client API in your own code, review timeout settings per request.
Set up a dedicated device to handle encryption/decryption of incoming requests.
Reduce request to the Reference Data service by implementing Reference Data dictionary caching.
Use a Media Library CDN.

Security configuration tasks

Refer to the Content Delivery section of the Security guide.

Redacting contact IP addresses

The CD role stores all incoming contact IP addresses in the InteractionFacets table in the xDB Collection database. You can choose to have the CD role redact these IP addresses by changing the value attribute of the Analytics.RedactIpAddress setting in the <wwwroot>\App_Config\Sitecore\Marketing.Tracking\Sitecore.Analytics.Tracking.config file.

RequestResponse

<configuration>
  <sitecore>
    <settings>
      <setting name="Analytics.RedactIpAddress" value="false" />
    </settings>
  </sitecore>
</configuration>

The following table shows the results of setting the value attribute to either true or false:

Value	Result
`false` (default)	All incoming contact IP addresses are stored in plain text.
`true`	All incoming contact IP addresses are redacted, and empty IP addresses (0.0.0.0) are stored instead. Important You lose the ability to determine contact IP addresses if you configure this setting to `true`.

Encrypting contact IP addresses

All incoming IP addresses are stored in Web database by default. You can change this in the configuration. The IP addresses are encrypted by the Sitecore.CES.GeoIp.Core.IpHashing.IpHashProvider provider, using the MD5 algorithm and a random security string (a salt). You can specify the salt in the <wwwroot>\App_Config\Sitecore\ DetectionServices.Location\ Sitecore.CES.GeoIp.config configuration file.

RequestResponse

<configuration>
  <sitecore>
    <ipHashManager defaultProvider="default">
      <providers>
        <add
          name="default"
          salt="<SALT STRING>"
          type=" Sitecore.CES.GeoIp.Core.IpHashing.IpHashProvider, Sitecore.CES.GeoIp.Core" />
      </providers>
    </ipHashManager>
  </sitecore>
</configuration>

Important

We recommend that you always enter a salt string of at least six random characters. You must never change the salt string after deployment. If you do, future incoming contact IP addresses are encrypted differently, and you lose data integrity.

Note

Sitecore provides a tool called Hash Stored IPs. You use this tool when you upgrade from a Sitecore version earlier than 8.1, where IP addresses were not hashed.

General configuration tasks

The following general configuration tasks apply to the Content Delivery role:

Default topologies and packages

The following tables list the topologies that include the Content Delivery role and how the role is packaged by default.

Sitecore Installation Framework

The Content Delivery role is available in the following default topologies for the Sitecore Installation Framework:

Topology	Web Deploy Packages	Description
XP Single	`Sitecore 9.X.X rev. XXXXXX (OnPrem)_single.scwdp.zip`	Content Delivery is bundled with all other Core roles. Not recommended in a production environment.
XP Scaled	`Sitecore 9.X.X rev. XXXXXX (OnPrem)_cd.scwdp.zip`	Standalone instance of Content Delivery.
XM Scaled	`Sitecore 9.X.X rev. XXXXXX (XM) (OnPrem)_cd.scwdp.zip`	Standalone instance of Content Delivery.

Topology

Web Deploy Packages

Description

XP Single

Sitecore 9.X.X rev. XXXXXX (OnPrem)_single.scwdp.zip

Content Delivery is bundled with all other Core roles.

Not recommended in a production environment.

XP Scaled

Sitecore 9.X.X rev. XXXXXX (OnPrem)_cd.scwdp.zip

Standalone instance of Content Delivery.

XM Scaled

Sitecore 9.X.X rev. XXXXXX (XM) (OnPrem)_cd.scwdp.zip

Standalone instance of Content Delivery.

Sitecore Azure Toolkit

The Content Delivery role is available in the following default topologies for the Sitecore Azure Toolkit:

Topology	Web Deploy Packages	Description
XP Single	`Sitecore 9.X.X rev. XXXXXX (Cloud)_single.scwdp.zip`	Content Delivery is bundled with all other Core roles. Not recommended in a production environment.
XP Scaled	`Sitecore 9.X.X rev. XXXXXX (Cloud)_cd.scwdp.zip`	Standalone instance of Content Delivery.
XM Scaled	`Sitecore 9.X.X rev. 002893 (XM) (Cloud)_cd.scwdp.zip`	Standalone instance of Content Delivery.
XM Single	`Sitecore 9.2.0 rev. 002893 (XM) (Cloud)_single.scwdp.zip`	Content Delivery is bundled with Content Management. Not recommended in a production environment.

Do you have some feedback for us?

If you have suggestions for improving this article,