| Component | Configuration | Description | Configuration | Notes |
| Publisher | | Publisher threads (rendering) | | The number of threads configured for Publisher (rendering) can be equal to number of cores of the publisher machine. This can be as high as 2 X no of cores.
This also depends on whether the publisher is running on a separate machine or running alongside other services.
It is advised to monitor CPU usage with using threads equal to 2 X number of cores and check if CPU usage is within safe limits (not more than 70-80%) during rendering. |
| Transport Service | cd_transport_conf.xml | Workers thread configurations |
<Workers NormalPriorityPoolSize="5" HighPriorityPoolSize="5"
TransportPriorityPoolSize="0"/>
Note: set TransportPriorityPoolSize to 0 to have unlimited. | Default value set at the transport side is 5 worker threads. This can be increased based on the increase in Publisher threads. This will ensure that Transport processes and tracks more packages at a time.
This can be increased between 10-15 in proportion to increase in number of publisher threads.
Note that if this is increased too far, the transport service will create an excessive number of http threads. |
| Transport Service | cd_transport_conf.xml | Max connections per route |
<Senders ..... MaxConnectionsPerRoute="600">
| Recommendation is to always increase this as the default is only 5! |
| Transport Service | cd_transport_conf.xml | Send timeout for packages |
<Senders ..... SendTimeout="60000">
| Default value is 1min. This can be increased to 5 mins (300000) if slow network connections are expected and/or regular large package sizes.
Also make sure that load balancer or any other proxy server in between has the proper timeout set, otherwise the Transport service can fail with "Gateway timeout error" and this property setting can have no effect.
Note: This should not be increased to a very high value as this can lead to functional deadlocks and publishing will become slower and eventually get blocked. Maximum value should not exceed 8 mins. |
| Transport Service | cd_transport_conf.xml | HTTP connection timeout |
<Senders ..... HttpConnectionTimeout="60000">
| Default value is 1 minute. This can be increased to 5 mins (300000) if we are expecting slow network connections and/or regular large package sizes.
Also make sure that load balancer or any other proxy server in between has propper timeout set, otherwise we can fail with "Gateway timeout error" and this property setting can have no effect.
Note: This setting should always be lower or equal to the SendTimeout parameter. |
| Deployer | application.properties | Deployer upload limit |
# specifies the maximum size permitted for uploaded files.
spring.http.multipart.max-file-size=1000Mb
# specifies the maximum size allowed for
multipart/form-data requests.
spring.http.multipart.max-request-size=1000Mb
| If we want to allow bigger packages to be deployed, then we need to increase limits in config/application.properties of deployer services.
Along with this we may have to change the Java memory values for deployer (mentioned below) |
| Deployer | Service startup scripts | Java memory settings |
-XX:+CMSScavengeBeforeRemark
-XX:+CMSParallelRemarkEnabled
-XX:+UseConcMarkSweepGC
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70
-XX:-UseLargePagesIndividualAllocation
-XX:MaxTenuringThreshold=12
-XX:NewRatio=1
-XX:GCTimeRatio=80
-XX:ParallelGCThreads=4
Note
- It's good to keep xms high
- For JDK 8 it's important to use parallel GCing (for JDK 11, the default G1 is fine)
- Make sure your Eden space is big enough. | The min and max values set for the JVM. Default settings are 512 & 1024.
This needs to be increased if we are expecting very large packages deployed. Indicative value is max memory to be 1.5 times the max package size expected. It also depends on how many big packages are published at certain point of time. |
| Deployer | deployer-conf.xml | Deployer workers (for Queues) |
<Property Name="Workers" Value="10" />
| Default value is 10. Note: In most of the scenarios, this values is sufficient and should not be increased. Increasing this to higher value may result in potential deadlock at Database level. Since we have retry mechanism implemented, these deadlocks can decrease the performance of the deployer.
The number of workers should not be set too high, as there will be a limit that the database transaction mechanism can cope with. Customers using more than 24 probably won't see any benefits. |
| Deployer (Combined or Worker) | cd_storage_conf.xml | Pool configuration | Oracle
<Pool Type="jdbc" Size="50" MonitorInterval="60" IdleTimeout="120"
CheckoutTimeout="120" MinEvictableIdleTimeout="-1"
ValidationQuery="select 1 from dual" TestOnBorrow="true"/>
MSSQL
<Pool Type="jdbc" Size="50" MonitorInterval="60" IdleTimeout="120"
CheckoutTimeout="120" MinEvictableIdleTimeout="-1"
ValidationQuery="SELECT 1" TestOnBorrow="true"/>
| It is recommended to use the Pool configuration as specified when their requirement is to publish large number items at a time.
The ValidationQuery parameter in conjunction with TestOnBorrow parameter is recommended to use in any scenario.
Size: Refers to minimum number of idle connections in a pool. This must be greater than the number of workers configured in the cd_deployer_conf.xml. Increasing this number has been shown to be effective at increasing throughput. We have customers running on 1000.
Other properties in the configuration can be used as it is which is help in optimizing connection pool configurations.
Note:
For Web 8.1.1, hotfix CD_8.1.1.3823 or later is required. |
| Deployer MSSQL database | Database | DB configuration |
ALTER DATABASE <Tridion_Broker> SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE <Tridion_Broker> SET READ_COMMITTED_SNAPSHOT ON
EXEC SP_UPDATESTATS
| It is recommended to set snapshot isolation to MSSQL database to prevent deadlocks. |
| Deployer State Store | deployer-conf.xml | DB configuration | Oracle
<State><Storage><Property Name="validationQuery"
Value="select 1 from dual"/></State></Storage>
MSSQL
<State><Storage><Property Name="validationQuery"
Value="select 1"/></State></Storage>
| The 'validationQuery' parameter is recommended to use in any scenario. |
| Deployer State Store | deployer-conf.xml | DB configuration |
<State>
<Storage Adapter="mssql"
driver="com.microsoft.sqlserver.jdbc.SQLServerDriver" >
<Property Name="maxActive" Value="8"/>
<Property Name="maxIdle" Value="8"/>
<Property Name="initialSize" Value="0"/>
</Storage>
</State>
| As part of hotfix CD_8.5.0.17389, the ability was introducted to tune the State Store pool size. Defaults are shown here. This can be used to increase the capacity of the State Store pool. However, under normal setups, the defaults should be sufficient. |
| Redis Binary Store | deployer-conf.xml | Configuration |
<BinaryStorage Id="RedisStorage" Adapter="RedisBlobStorage">
<Property Name="Host" Value="${storageHost}"/>
<Property Name="Port" Value="${storagePort}"/>
<Property Name="Password" Value="..."/>
<Property Name="Timeout" Value="20000"/>
<Property Name="MaxTotal" Value="8"/>
<Property Name="MaxIdle" Value="8"/>
<Property Name="MinIdle" Value="0"/>
</BinaryStorage>
| As part of hotfix CD_8.5.0.17389, the ability to tune the Redis binary storage was introduced. Defaults are shown here. This can be used to increase the capacity of the Redis binary processing. |
| Deployer State Store | Database | Configuration | The full list of constraints which are required by the State Store tables.
ALTER TABLE EXECUTION
ADD CONSTRAINT PK_EXECUTION_ID PRIMARY KEY CLUSTERED (EXECUTION_ID)
WITH FILLFACTOR = 80
go
ALTER TABLE PIPELINE
ADD CONSTRAINT PK_PIPELINE_PIPELINE_ID PRIMARY KEY CLUSTERED (EXECUTION_ID, PIPELINE_ID)
WITH FILLFACTOR = 80
go
ALTER TABLE STEP
ADD CONSTRAINT PK_STEP_EXECUTION_ID PRIMARY KEY CLUSTERED (EXECUTION_ID, PIPELINE_ID, STEP_ID)
WITH FILLFACTOR = 80
go
ALTER TABLE EXECUTION_PROPERTY
ADD CONSTRAINT PK_EXECUTION_PROPERTY_ID PRIMARY KEY CLUSTERED (ID)
WITH FILLFACTOR = 80
go
ALTER TABLE PIPELINE
ADD CONSTRAINT FK_PIPELINE FOREIGN KEY (EXECUTION_ID)
REFERENCES EXECUTION (EXECUTION_ID) ON DELETE CASCADE ON UPDATE CASCADE
go
ALTER TABLE STEP
ADD CONSTRAINT FK_STEP FOREIGN KEY (EXECUTION_ID, PIPELINE_ID)
REFERENCES PIPELINE (EXECUTION_ID, PIPELINE_ID) ON DELETE CASCADE ON UPDATE CASCADE
go
ALTER TABLE EXECUTION_PROPERTY
ADD CONSTRAINT FK_EXECUTION_PROPERTY FOREIGN KEY (EXECUTION_ID, PIPELINE_ID, STEP_ID)
REFERENCES STEP (EXECUTION_ID, PIPELINE_ID, STEP_ID) ON DELETE CASCADE ON UPDATE CASCADE
go
CREATE INDEX IDX_EXECUTION_PROPERTY_FK
ON EXECUTION_PROPERTY (EXECUTION_ID, PIPELINE_ID, STEP_ID)
WITH FILLFACTOR = 80
GO
| The State Store database works incorrectly if any required constraint or index was not added to the database. If a database is incorrectly configured, it is possible to see deadlocks and failed transactions. |
